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FOREWORD: 
ABOUT THIS DOCUMENT 


This edition of the Technical Architecture Framework for Information Management (TAFIM) 
replaces Version 2.0, dated 30 June 1994. Version 3.0 comprises eight volumes, as listed on the 
following configuration management page. 


TAFIM HARMONIZATION AND ALIGNMENT 


This TAFIM version is the result of a review and comment coordination period that began with 
the release of the 30 September 1995 Version 3.0 Draft. During this coordination period, a 
number of extremely significant activities were initiated by DoD. As a result, the version of the 
TAFIM that was valid at the beginning of the coordination period is now “out of step” with the 
direction and preliminary outcomes of these DoD activities. Work on a complete TAFIM update 
is underway to reflect the policy, guidance, and recommendations coming from theses activities 
as they near completion. Each TAFIM volume will be released as it is updated. Specifically, the 
next TAFIM release will fully reflect decisions stemming from the following: 


e The DoD 5000 Series of acquisition policy and procedure documents 
e The Joint Technical Architecture (JTA), currently a preliminary draft document under review. 


e The C4ISR Integrated Task Force (ITF) recommendations on Operational, Systems, and 
Technical architectures. 


SUMMARY OF MAJOR CHANGES AND EXPECTED UPDATES 


This document, Volume 3 of the TAFIM, contains minor substantive changes from Volume 3 of 
Version 2.0, most of which are intended to resolve internal inconsistencies or to bring the 
guidance provided in this volume more in line with current policies. Work remains to be done to 
fully reflect the impact of the documents and decisions noted above; this edition of the TAFIM 
has been released to serve as a baseline and to make available throughout the DoD community 
the additions and modifications that have been implemented to date. 


A NOTE ON VERSION NUMBERING 


A version numbering scheme approved by the Architecture Methodology Working Group will 
control the version numbers applied to all future editions of TAFIM volumes. Version numbers 
will be applied and incremented as follows: 


e This edition of the TAFIM is the official Version 3.0. 


e From this point forward, single volumes will be updated and republished as needed. The 
second digit in the version number will be incremented each time (e.g., Volume 7 Version 
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3.1). The new version number will be applied only to the volume(s) that are updated at that 
time. There is no limit to the number of times the second digit can be changed to account for 
new editions of particular volumes. 


e Onan infrequent basis (e.g., every two years or more), the entire TAFIM set will be 
republished at once. Only when all volumes are released simultaneously will the first digit in 
the version number be changed. The next complete version will be designated Version 4.0. 


e TAFIM volumes bearing a two-digit version number (e.g., Version 3.0, 3.1, etc.) without the 
DRAFT designation are final, official versions of the TAFIM. Only the TAFIM program 
manager can change the two-digit version number on a volume. 


e A third digit can be added to the version number as needed to contro] working drafts, 
proposed volumes, internal review drafts, and other unofficial releases. The sponsoring 
organization can append and change this digit as desired. 


Certain TAFIM volumes developed for purposes outside the TAFIM may appear under a 
different title and with a different version number from those specified in the configuration 
management page. These editions are not official releases of TAFIM volumes. 


DISTRIBUTION 


Version 3.0 is available for download from the DISA Information Technology Standards 
Information (ITSI) bulletin board system (BBS). Users are welcome to add the TAFIM files to 
individual organizations’ BBSs or file servers to facilitate wider availability. 


This final release of Version 3.0 will be made available on the World Wide Web (WWW) shortly 
after hard-copy publication. The Defense Information Systems Agency (DISA) 15 also 
investigating other electronic distribution approaches to facilitate access to the TAFIM and to 
enhance its usability. 
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TAFIM Document Configuration Management Page 


The latest authorized versions of the TAFIM volumes are as follows: 


Volume 1: Overview 30 April 1996 
Volume 2: Technical Reference Model 30 April 1996 
Volume 3: Architecture Concepts & Design Guidance 30 April 1996 
Volume 4: DoD SBA Planning Guide 30 April 1996 
Volume 5: Program Manager’s Guide for Open Systems 30 April 1996 
Volume 6: DoD Goal Security Architecture 30 April 1996 
Volume 7: Adopted Information Technology Standards ; 30 April 1996 
Volume 8: HCI Style Guide 30 April 1996 


Working drafts may have been released by volume sponsors for internal coordination purposes. 
It is not necessary for the general reader to obtain and incorporate these unofficial, working 
drafts. 


Note: Only those versions listed above as authorized versions represent official editions of the 
TAFIM. 
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1.0 INTRODUCTION 


The Technical Architecture Framework for Information Management (TAFIM) characterizes an 
information system as composed of data, mission-specific applications, and a technical 
infrastructure consisting of support applications, application platforms, and communications 
networks. This document presents technical architecture concepts and design guidance for 
information systems in the Department of Defense (DoD). As part of the TAFIM, this volume 
provides guidance for the evolution of the DoD’s technical infrastructure in support of specific 
mission requirements. The data and mission-specific software architectures are critical elements 
in information system development. Guidance on their development and use will be provided in 
separate documents outside of the TAFIM. 


1.1 SCOPE 


Volume 3 provides concepts and design guidance that will help architects, integrators, and 
system designers to develop information systems technical architectures. These concepts and 
guidance should be considered in the context of the Technical Reference Model presented in 
Volume 2. 


The contents of this volume contrast with the TAFIM Volume 2, which describes services and 
interfaces between entities. This volume addresses components and the allocation of services to 
the components. 


1.2 DOCUMENT ORGANIZATION 


Volume 3 of the TAFIM consists of three sections and four appendices. Section 2 discusses 
several architecture concepts of interest to architects, designers, and developers. Section 3 
presents design guidance based on availability and maturity of technology. Appendix A provides 
acronyms and definitions. Appendix B provides a definition and discussion of open systems. 
Appendix C contains references. Appendix D contains a template for submitting comments on 
this volume. 
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2.0 ARCHITECTURE CONCEPTS 


The DoD vision described in Volume | depicts a future information technology environment that 
includes: 


e Shared global databases 

e Shared utility services 

e Centrally managed and operated backbone network 

e Distributed data 

e Distributed processes 

e Standard user interface 

e Transparent information, computing, and information utility 
e Individual tailoring of information resources. 


The new DoD architectural framework supports an orderly migration from existing legacy 
systems to DoD standard systems operating in a distributed computing environment that 
incorporates the above features. Over time, systems will be reengineered or developed to 
conform to the architecture concepts and standards in the TAFIM. As this occurs, a distributed 
computing environment will evolve, where processing nodes are constructed to provide services 
to meet the requirements of the DoD community. 


Figure 2-1 depicts a distributed computing environment, which includes platforms and, 
optionally, support applications and mission-area applications. The external environment shown 
in the figure consists of entities that are external to the application software and the platform 
(€.g., users, Communications networks). The actual features of an implementation will be 
dictated by functional requirements and processing efficiency. The enterprise backbone network 
in this distributed computing environment will provide end-to-end communications services that 
connect all of the processing nodes, down to an individual's workstation. Through the network, 
authorized users and applications will have access to all required data and processing resources 
without having to know the location of the resources. This will include access to shared 
enterprise global databases and utility services by distributed applications and fixed and mobile 
users. Resources will be provided through a transparent combination of local and remote 
processes. Distribution of redundant enterprise data and processing resources across multiple 
processing nodes will provide processing efficiency, reliability, and survivability. 
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Figure 2-1. Distributed Computing Context 
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2.1 ARCHITECTURE DEFINITIONS 


This section sets the stage for the architecture concepts to be described. It provides basic 
definitions within the context of a mode! for architectures. 


2.1.1 Architecture Model 


A technical architecture defines components, interfaces, services, and the framework within 
which they interoperate. Components provide either information processing or communications 
services. A component provides a complete service or part of a service. A component may also 
provide more than one service. Interfaces link components so that they may interoperate. Figure 
2-2 depicts a model of these relationships. 


Figure 2-3 depicts service components and their interfaces. The TAFIM provides guidance on 
the following interfaces: a) between applications (mission-area and support applications) and 
service components, b) between separate service components, and c) between service 
components and the external environment. 


Services are invoked through an interface, which defines the access rules. Two types of 
interfaces are described in the Technical Reference Model: an application program interface 
(API), which defines the rules and protocols used by an application to invoke a service; and an 
external environment interface (EEI), which defines the rules and protocols for invoking the 
external environment services. EEI services are provided to support users, peripherals, and 
remote processors. Volume 2 defines an AP] as the interface that enables applications to invoke 
application platform services. To satisfy DoD Information Management (IM) requirements, the 
TAFIM has applied the definition of an API to any service provided to an application through a 
programming interface. This interpretation was necessary to meet two distinct requirements. 


Component Component 


Interface 


Service Service 


Figure 2-2. Model of Information System Architecture 
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Figure 2-3. Technical Architecture Service Context 


First, it supports the use of services not provided by the application platform. Recognizing that 
many reusable services are not covered under the platform service categories, the TAFIM has 
split the applications into mission-area applications and support applications. The support 
applications provide common reusable services, such as word processing and electronic mail 
(E-mail), to mission-area applications and other support applications. To support mission-area 
and support application portability, DoD has a requirement for standard application interfaces to 
these services. Applying the definition of the API to address this interface Supports the potential 
future migration of services between the support applications and platforms. 


Second, this expansion supports the distribution of computing and communications resources 
throughout the network. The use of one platform component'’s service by another platform 
component is defined as a system internal interface (SII) by POSIX P1003.0. The DoD 
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requirement is for platform components to use the same API that an application uses when 
requesting services from other platform components. For example, if an Information Resource 
Dictionary System (IRDS)-compliant dictionary has a requirement to store data in a database, it 
should use the Structured Query Language (SQL) API to invoke the services of a Relational 
Database Management System (RDBMS). This will minimize unique dependencies between 
platform components, enhancing the capability to replace one platform component with another. 
It will also provide DoD with the maximum flexibility possible in distributing computing and 
communication resources throughout the network. 


2.1.2 Architecture Views 


Depending on the area of responsibility of the architect or designer, an architecture may be 
viewed from different perspectives. For example, the designer responsible for computing 
perceives the architecture with a different focus than the designer responsible for data 
management. The architect responsible for the overall system has yet another focus. The views 
presented in the remaining subsections of Section 2 (2.2, 2.3, 2.4, 2.5) describe architecture 
concepts from different perspectives. Each of these views addresses components, interfaces, and 
allocation of services critical to the view. 


2.2 COMPUTING VIEW 


This view of the technical architecture focuses on computing models that are appropriate for a 
distributed computing environment. To support the migration of legacy systems, the section also 
presents models that are appropriate for a centralized environment. The definitions of many of 
the computing models (e.g., host-based, master-slave, and three-tiered) historically preceded the 
definition of the client/server model, which attempts to be a general-purpose model. In most 
cases the models have not been redefined in the computing literature in terms of contrasts with 
the client/server model. Therefore, some of the distinctions of features are not always clean. In 
general, however, the models are distinguished by the allocation of functions for an information 
system application to various components (e.g., terminals, computer platforms). These functions 
that make up an information system application are presentation, application function, and data 
management. 


2.2.1 Client/Server Model 


Client/server processing is a special type of distributed computing termed cooperative processing 
because the clients and servers cooperate in the processing of a total application (presentation, 
functional processing, data management). In the model, clients are processes that request 
services, and servers are processes that provide services. Clients and servers can be located on 
the same processor, different multiprocessor nodes, or on separate processors at remote locations. 
The client typically initiates communications with the server. The server typically does not 
initiate a request with a client. A server may support many clients and may act as a client to 
another server. Figure 2-4 depicts the basic client/server model. 


Volume 3 Version 3.0 
Architecture Concepts and Design Guidance 2-5 30 April 1996 


Platform Platform 


Request 


Network 


Figure 2-4. Basic Client/Server Model 


Clients tend to be generalized and can run on one of many nodes. Servers tend to be specialized 
and run on a few nodes. Clients are typically implemented as a call to a routine. Servers are 
typically implemented as a continuous process waiting for service requests (from clients). Many 
client/server implementations involve remote communications across a network. However, 
nothing in the client/server model dictates remote communications, and the physical location of 
clients 15 usually transparent to the server. The communication between a client and a server may 
involve a local communication between two independent processes on the same machine. 


An application program can be considered to consist of three parts—the application function, the 
presentation, and the data management. In general, any of these can be assigned to either a client 
or a server. The assignment of each of these program parts to clients and servers can define 
client/server configurations. The following are five client/server configurations, which 
demonstrate the flexibility of the client/server model in implementing distributed paradigms. 

The terms “remote” and “distributed” are from the perspective of the application function portion 
of the processing: 


e Distributed Presentation 

e Remote Presentation 

e Remote Data Management 
e Distributed Function 


e Distributed Data Management. 
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These five client/server configurations, which are based on a Gartner Group Report, are 
frequently cited in computing literature, but some sources find that they do not represent the 
current state of commercial-off-the-shelf (COTS) offerings. For example, the Defense 
Information Systems Agency’s (DISA) Client Server Migration Guidance presents three models 
as alternatives to the above popular configurations. They are Presentation Logic Functions, 
Business Logic Functions, and Data Management Functions. Their rationale is as follows. The 
distinctions between remote and distributed presentation, data management, and distributed 
function do not relate easily to COTS products. As an example, the remote data management 
model states that the presentation functions reside entirely in a client. In practice, virtually every 
implementation places some functions, however small, in a server. This places these 
implementations into the distributed presentation model category. Similar situations occur for 
the other models. 


Another client/server configuration growing in popularity is the multitiered architecture. The 
multitiered architecture and the five popular client/server configurations that are listed above are 
discussed in the following sections. The five client/server configurations are presented in Figure 
2-5. 


Distributed Remote Remote Data Distributed Distributed Data 
Presentation Presentation Management Function Management 
Data Data Data Data Data 
Management Management Management Management Management 
Application Application Application 
Server Function Function unetion 


Presentation 


Network 


Data 
Management 
| Application Application . Application 


Source: Gartner Group 


Figure 2-5. Client/Server Configurations 
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2.2.1.1 Distributed Presentation 


This model distributes responsibility for presentation between the client and the server. An 
architecture that implements this model is the X Window architecture. In such an 
implementation, X terminals are used as client platforms, which contain presentation functions. 
All other functions (application function and data management), including additional 
presentation capability, are on the server. 


2.2.1.2 Remote Presentation 


This configuration separates presentation logic from functional logic by locating the entire 
presentation function on the client workstation. The client is responsible for the user interface, 
accepting and validating user input, and sending requests to and receiving results of requests 
from the server. The advantage of this model 15 that client and servers are separated by a 
network, keeping presentation logic off the network. In this scenario, clients request data 
management and application functional processing services from servers. 


2.2.1.3 Remote Data Management 


In this configuration, a central server specializes in data management, which might include data 
security, integrity, and processing database requests from the client. The management of data is 
separate from the application. This model can be used to support central subject area databases 
serving One or more remote clients. An example configuration is a database machine or database 
server attached to clients on workstations. 


2.2.1.4 Distributed Function 


In this configuration, multiple servers provide specific application processing functions for client 
applications. The advantages offered through the distribution of application functions include 
the reduction of redundant code, centralized management and operation of complex processing 
functions, the ability to distribute some application functions closer to the end user, and the 
ability to configure and tune specialized servers for maximum processing efficiency. Examples 
of servers that provide distributed application functions include mail servers, print servers, 
transaction processors, communication servers, mission-area application servers, and directory 
servers. 


2.2.1.5 Distributed Data Management 


In this configuration, the responsibility for data management is split among more than one server. 


When one data management server, which may or may not be local to the client application, 
cannot satisfy a request for data, it in turn becomes a client to another data management server 
that is capable of satisfying the original request. The original client application is unaware that 
more than one server participated in processing the request. This variation can be introduced 
during application consolidation and migration, where data is distributed across multiple legacy 
databases. It can also be used to support an environment where a logical subject area database is 
spread over several physical databases. An example configuration is a distributed database on 
more than one platform. 
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2.2.1.6 The Multitiered Architecture 


All of the client/server configurations presented so far in this section (2.2.1) show functions 
(presentation, application logic, and data management) distributed over two virtual platforms. 
These can be considered two-tiered architectures. Multitiered client/server architectures with 
three or more tiers have been proposed and are gaining in popularity. 


In multitiered architectures, functions are distributed over multiple virtual (or logical) platforms. 
These architectures accommodate the partitioning of applications so that user interfaces reside on 
the user’s platform, functional services reside on one or more other networked platforms, and 
data and legacy systems reside on additional networked platforms. 


2.2.2 Host-Based Model 


The host-based model is an approach that provides centralized processing on a host machine — 
that is, it provides no distributed processing. The typical configuration is a mainframe with 
attached dumb terminals. The central computer does all of the processing (e.g., presentation, 
application functional processing, data management). Figure 2-6 presents an example host-based 
configuration. 


2.2.3 Master-Slave and Hierarchic Models 


In this model, slave computers are attached to a master computer. In terms of distribution, the 
master-slave model is one step up from the host-based model. Distribution is provided in one 
direction—from the master to the slaves. The slave computers perform application processing 
only when directed to by the master computer. In addition, slave processors can perform limited 
local processing, such as editing, function key processing, and field validation. A typical 
configuration might be a mainframe as the master with personal computers (PC) as the slaves 
acting as intelligent terminals, as illustrated in Figure 2-6. 


The hierarchic model is an extension of the master-slave model with more distribution 
capabilities. In this approach, the top layer is usually a powerful mainframe, which acts as a 
server to the second tier. The second layer consists of local area network (LAN) servers and 
clients to the first layer as well as servers to the third layer. The third layer consists of PCs and 
workstations. This model has been described as adding true distributed processing to the 
master-slave model. Figure 2-6 shows an example hierarchic model in the third configuration. 


2.2.4 Peer-to-Peer Model 


In the peer-to-peer model there are coordinating processes. All of the computers are servers in 
that they can receive requests for services and respond to them; and all of the computers are 
clients in that they can send requests for services to other computers. In current implementations, 
there often are redundant functions on the participating platforms. 
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Figure 2-6. Host-Based, Master-Slave, and Hierarchic Models 


Attempts have been made to implement the model for distributed heterogeneous (or federated) 
database systems. This model could be considered a special case of the client/server model, in 
which all platforms are both servers and clients. Figure 2-7 (A) shows an example peer-to-peer 
configuration in which all platforms have complete functions. 


2.2.5 Distributed Object Management Model ᾿ 


In this mode] the remote procedure calls typically used for communication in the client/server 
and other distributed processing models are replaced by messages sent to objects. The services 
provided by systems on a network are treated as objects. A requester need not know the details 
of how the object is configured. The approach requires: 1) a mechanism to dispatch messages; 
2) a mechanism to coordinate delivery of messages; and 3) applications and services that support 
a messaging interface. This approach does not contrast with client/server or peer-to-peer models 
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but specifies a consistent interface for communicating between cooperating platforms. It is 
considered by some as an implementation approach for client/server and peer-to-peer models. 
Figure 2-7 presents two distributed object model examples. Example B shows how a client/server 
configuration would be altered to accommodate the distributed object management model. 
Example C shows how a peer-to-peer model would be altered to accomplish distributed object 
management. 


A Peer-to-Peer 


Platform Platform 


Data Data 
Management Management 
Appiication Application 
Function Function 


C Distributed Object Management 


Platform Platform 


Data 
Management 
Application 
Function 


Data 
Management 


Platform 


Data 
Management 


Application 
Function 


Application 
Function 


Presentation 


Standard 
interface 


B Distributed Object 


Management 
Server 


Data 
Management 
Application 
Function 


\ 


Management 
Standard 98 
aera ως 
Function 


4 Client 


Figure 2-7. Peer-to-Peer and Distributed Object Management Models 


Platform 


Volume 3 Version 3.0 
Architecture Concepts and Design Guidance 2-11 30 April 1996 


NN 


The Object Management Group (OMG), a consortium of industry participants working toward 
object standards, has developed an architecture — the Common Object Request Broker 
Architecture (CORBA), which specifies the protocol a client application must use to 
communicate with an Object Request Broker (ORB), which provides services. The ORB 
specifies how objects can transparently make requests and receive responses. In addition, 
Microsoft’s Object Linking and Embedding (OLE) standard for Windows 15 an example of an 
implementation of distributed object management, whereby any OLE-compatible application can 
work with data from any other OLE-compatible application. 


2.3 DATA MANAGEMENT VIEW 


The DoD is accomplishing a phased convergence to an open systems environment. This involves 
the selection of migration systems, defining interim architectures, and performing functional and 
technical integration. Under the TAFIM, data management services may be provided by a wide 
range of implementations. Some examples are: 


e Mega centers providing functionally oriented corporate databases supporting local and 
remote data requirements 


e Distributed database management systems that support the interactive use of partitioned 
and partially replicated databases 


e File systems provided by operating systems, which may be used by both interactive and 
batch processing applications. 


Data management services include the storage, retrieval, manipulation, backup, restart/recovery, 
security, and associated functions for text, numeric data, and complex data such as documents, 
graphics, images, audio, and video. The operating system provides file management services, but 
they are considered here because many legacy databases exist as one or more files without the 
services provided by a Database Management System (DBMS). 


Major components that provide data management services that are discussed in this section are: 
e DBMSs 

e Data dictionary/directory systems 

e Data security. 


These are critical aspects of data management for the following reasons. The DBMS is the most 
critical component of any data management capability, and a data dictionary/directory system is 
necessary in conjunction with the DBMS as a tool to aid the administration of the database. Data 
security 1s a necessary part of DoD’s overall policy for secure information processing. 
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2.3.1 Database Management Systems 


A DBMS provides for the systematic management of data. This data management component 
provides services and capabilities for defining the data, structuring the data, accessing the data, as 
well as security and recovery of the data. A DBMS performs the following functions: 


e Structures data in a consistent way 

e Provides access to the data 

e Minimizes duplication 

e Allows reorganization, that is, changes in data content, structure, and size 
e Supports programming interfaces 

e Provides security and control. 

A DBMS must provide: 

e Persistence—The data continues to exist after the application’s execution has completed 
e Secondary storage management 

e Concurrency 

e Recovery 


e Data definition language/data manipulation language (DDL/DML) - it may be a 
graphical interface. 


2.3.1.1 Database Models 


The logical data model that underlies the database characterizes a DBMS. The common logical 
data models are listed in Figure 2-8. The subsections below discuss each of these database types. 


2.3.1.1.1 The Relational Model 
A RDBMS structures data into tables that have certain properties: 
e Each row in the table is distinct from every other row. 


e Each row contains only atomic data; that is, there is no repeating data or such structures 
| as arrays. 


e Each column in the relational table defines named data fields or attributes. 
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Figure 2-8. Summary of Data Models 


A row of data in a relational database is commonly referred to as a tuple; an example would be a 
record in a file. An example of a column in a relational table would be a field in a record. A 
collection of related tables in the relational model makes up a database. 


The mathematical theory of relations underlies the relational model — both the organization of 
data and the languages that manipulate the data. Edgar Codd, then at International Business 
Machines (IBM), developed the relational model in 1973. It has been popular, in terms of 
commercial use, since the early 1980s. 


2.3.1.1.2 The Hierarchical Model 


The hierarchical data model organizes data in a tree structure. There is a hierarchy of parent and 
child data segments. This structure implies that a record can have repeating information, 
generally in the child data segments. For example, an organization might store information about 
an employee, such as name, employee number, department, salary. The organization might also 
store information about an employee's children, such as name and date of birth. The employee 
and children data forms a hierarchy, where the employee data represents the parent segment and 
the children data represents the child segment. If an employee has three children, then there 

_ would be three child segments associated with one employee segment. In a hierarchical database 
the parent-child relationship is one to many. This restricts a child segment to having only one 
parent segment. Hierarchical DBMSs were popular from the late 1960s, with the introduction of 
IBM's Information Management System (IMS) DBMS, through the 1970s. 


2.3.1.1.3 The Network Model 


The popularity of the network data model coincided with the popularity of the hierarchical data 
mode]. Some data were more naturally modeled with more than one parent per child. So, the 
network model permitted the modeling of many-to-many relationships in data. In 1971, the 
Conference on Data Systems Languages (CODASYL) formally defined the network model. The 
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basic data modeling construct in the network model is the set construct. A set consists of an 
owner record type, a Set name, and a member record type. A member record type can have that 
role in more than one set, hence the multiparent concept is supported. An owner record type can 
also be a member or owner in another set. The CODASYL network model is based on 
mathematical set theory. 


2.3.1.1.4 The Object-Oriented Model 


An object-oriented DBMS (OODBMS) must be both a DBMS and an object-oriented system. As 
a DBMS it must provide the capabilities identified above in Section 2.3.1. OODBMSs typically 
can model tabular data, complex data, hierarchical data, and networks of data. The following are 
mandatory features an object-oriented system should support: 


ὁ Complex objects -- e.g., objects may be composed of other objects. 
e Object identity — Each object has a unique identifier external to the data. 


e Encapsulation — An object consists of data and the programs (or methods) that 
manipulate it. 


e Types or classes -- A class is a collection of similar objects. 
e Inheritance — Subclasses inherit data attributes and methods from classes. 


Φ OQOverriding with late binding — The method particular to a subclass can override the 
method of a class at run time. 


e Extensibility —e.g., a user may define new objects. 


e Computational completeness — A general purpose language, such as Ada, C, or C++, 
is computationally complete. The special-purpose language SQL is not. Most 
OODBMSs incorporate a general-purpose programming language. 


2.3.1.1.5 Flat Files 


A flat file system is usually closely associated with a storage access method. An example is 

_ IBM's indexed sequential access method (ISAM). The models discussed earlier in this section 
are logical data models—flat files require the user to work with the physical layout of the data on a 
storage device. For example, the user must know the exact location of a data item in a record. In 
addition, flat files do not provide all of the services of a DBMS, such as naming of data, 
elimination of redundancy, and concurrency control. Further, there is no independence of the 
data and the application program. The application program must know the physical layout of the 
data. 
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2.3.1.2 Distributed DBMSs 


A distributed DBMS manages a database that is spread over more than one platform. The 
database can be based on any of the data models discussed above (except the flat file). The 
database can be replicated, partitioned, or a combination of both. A replicated database 15 one in 
which full or partial copies of the database exist on the different platforms. 


A major issue with replication is the method of maintaining consistency between the copies of 
the database. Some database management systems attempt to do this using complex 
synchronization algorithms (e.g., “two-phase commit” protocols). Many commercial! database 
vendors are offering a simpler form of replication in which a master copy 1s updated, then 
changes are propagated to the database copies by a replication server at a later time. 


A partitioned database is one in which part of the database 1s on one platform and parts are on 
other platforms. The partitioning of a database can be vertical or horizontal. A vertical 
partitioning puts some fields and the associated data on one platform and some fields and the 
associated data on another platform. For example, consider a database with the following fields: 
employee identification (ID), employee name, department, number of dependents, project 
assigned, salary rate, tax rate. One vertical partitioning might place employee ID, number of 
dependents, salary rate, and tax rate on one platform and employee name, department, and 
project assigned on another platform. A horizontal partitioning might keep all the fields on all 
the platforms but distribute the records. For example, a database with 100,000 records might put 
the first 50,000 records on one platform and the second 50,000 records on a second platform. 


Whether the distributed database is replicated or partitioned, a single DBMS manages the 
database. There is a single schema (description of the data in a database in terms of a data 
model, e.g., relational) for a distributed database. The distribution of the database is generally 
transparent to the user. The term “distributed DBMS” implies homogeneity. 


2.3.1.3 Distributed Heterogeneous DBMSs 


A distributed, heterogeneous database system is a set of independent databases, each with its own 
DBMS, presented to users as a single database and system. “Federated” is used synonymously 
with “distributed heterogeneous.” The heterogeneity refers to differences in data models (e.g., 
network and relational), DBMSs (e.g., Oracle and Ingres), platforms (e.g., VAX and Sun), or 
other. The simplest kinds of federated database systems are commonly called gateways. Ina 
gateway, one vendor (e.g., Oracle) provides single-direction access through its DBMS to another 
database managed by a different vendor’s DBMS (e.g., IBM’s DB2). The two DBMSs need not 
share the same data model. For example, many RDBMS vendors provide gateways to 
hierarchical and network DBMSs. 


There are federated database systems both on the market and in research that provide more 
general access to diverse DBMSs. These systems generally provide a schema integration 
component to integrate the schemas of the diverse databases and present them to the users as a 
single database, a query management component to distribute queries to the different DBMSs in 
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the federation, and a transaction management component, to distribute and manage the changes 
to the various databases in the federation. 


2.3.2 Data Dictionary/Directory Systems 


The second component providing data management services, the data dictionary/directory system 
(DD/DS), consists of utilities and systems necessary to catalog, document, manage, and use 
metadata (data about data). An example of metadata is the following definition: a 6-character 
long alphanumeric string, for which the first character is a letter of the alphabet and each of the 
remaining 5 characters is an integer between 0 and 9; the name for the string is employee ID. 
The DD/DS utilities make use of special files that contain the database schema. (A schema, 
using metadata, defines the content and structure of a database.) This schema is represented by a 
set of tables resulting from the compilation of DDL statements. The DD/DS is normally 
provided as part of a DBMS but is sometimes available from alternate sources. In the 
management of distributed data, distribution information may also be maintained in the network 
directory system. In this case, the interface between the DD/DS and the network directory 
system would be through the API of the network services component on the platform. 


In current environments, data dictionaries are usually integrated with the DBMS, and directory 
systems are typically limited to a single platform. Network directories are used to expand the 
DD/DS realms. The relationship between the DD/DS and the network directory is an intricate 
combination of physical and logical sources of data. 


2.3.3 Data Administration 


DoD Directive (DoDD) 8320.1 defines the data administration program for the DoD. Data 
administration properly addresses the data architecture, which is outside the scope of the TAFIM. 
We discuss it briefly here because of areas of overlap. It is concerned with all of the data 
resources of an enterprise, and as such there are overlaps with data management, which addresses 
data in databases. Two specific areas of overlap are the repository and database administration, 
which are discussed briefly below. 


2.3.3.1 Repository 


A repository 15 a system that manages all of the data of an enterprise, which includes data and 
process models and other enterprise information. Hence, the data in a repository is much more 
extensive than that ina DD/DS, which generally defines only the data making up a database. 


2.3.3.2 Database Administration 


Data administration and database administration are complementary processes. Data 
administration is responsible for data, data structure, and integration of data and processes. 
Database administration, on the other hand, includes the physical design, development, 
implementation, security, and maintenance of the physical databases. Database administration is 
responsible for managing and enforcing the enterprise’s policies related to individual databases. 
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2.3.4 Data Security 


The third component providing data management services is data security procedures and 
technology measures that are implemented to prevent unauthorized access, modification, use, and 
dissemination of data stored or processed by a computer system. Data security also includes data 
integrity (i.e., preserving the accuracy and validity of the data), and protecting the system from 
physical harm (including preventative measures and recovery procedures). 


Authorization control allows only authorized users to have access to the database at the 
appropriate level. Guidelines and procedures can be established for accountability, levels of 
control, and type of control. Authorization control for database systems differs from that in 
traditional file systems because, in a database system, it is not uncommon for different users to 
have different rights to the same data. This requirement encompasses the ability to specify 
subsets of data and to distinguish between groups of users. In addition, decentralized control of 
authorizations 15 of particular importance for distributed systems. 


Data protection is necessary to prevent unauthorized users from understanding the content of the 
database. Data encryption, as one of the primary methods for protecting data, is useful for both 
information stored on disk and for information exchanged on a network. 


2.4 COMMUNICATIONS VIEW 


The Open Systems Interconnection (OSI) model discussed in the following sections is useful as 
an aid to understanding the elements of successful network communication; however, it should 
be understood that the OSI protocols contained in the GOSIP standard are no longer mandated 
for use by Federal agencies. This change resulted from the emergence of Internet Protocol Suite 
(IPS) standards as the dominant standards for commercial hardware and software, and the 
relatively smaller number of OSI-compliant products available. Government agencies are now 
able to select cost-effective, off-the-shelf networking products that implement open standards, 
such as those developed by the Internet Engineering Task Force (IETF), International 
Telecommunications Union, and the International Organization for Standardization (ISO). The 
OSI protocols have been updated and are contained in the Industry/Government Open System 
Specification, NIST Publication 500-217. 


Communications networks are constructed of end devices (e.g., printers), processing nodes, 
communication nodes (switching elements), and the linking media that connect them. The 
communications network provides the means by which information is exchanged. Forms of 
information include data, imagery, voice, and video. Automated information systems (AISs) 
accept and process information using digital data formats rather than analog formats. Therefore, 
TAFIM communications concepts and guidance will focus on digital networks and digital 
Services. Integrated multimedia services are included. 


The communications view describes the architecture of DoD communications with respect to its 
geography (Section 2.4.1), discusses the OSI reference model, and describes a general framework 
intended to permit effective system analysis and planning for DoD (Section 2.4.2). 
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2.4.1 DoD Communications Infrastructure 


The communications infrastructure in the DoD will contain three transport components, local, 
regional/metropolitan, and global, as shown in Figure 2-9. The names of the transport 
components are based on their respective geographic extent, but there is also a hierarchical 
relationship among them. 


The transport components correspond to a network management structure in which management 
and contro! of network resources are distributed across the different levels. 


The local components relate to assets that are located relatively close together geographically. 
This component contains sustaining base communications assets for the fixed environment and 
tactical communications assets in the deployed environment. LANs, to which the majority of end 
devices will be connected, are included in this component. Standard interfaces will facilitate 
portability, flexibility, and interoperability of LANs and end devices. 


Regional and metropolitan area networks (MAN) are geographically dispersed over a large area. 
A regional or metropolitan network could connect local components at several sustaining bases 
in the fixed environment or connect theater tactical assets in the deployed environment. In most 
cases, regional and metropolitan networks are used to connect local networks. However, shared 
databases, regional processing platforms, and network management centers may connect directly 
or through a LAN. Standard interfaces will be provided to connect local networks and end 
devices. 
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Figure 2-9. Communications Infrastructure 
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Global or wide area networks (WAN) are located throughout the world, providing connectivity 
for regional and metropolitan networks in the fixed and deployed environment. In addition, 
deployed mobile assets, shared databases, and central processing centers can connect directly to 
the global network as required. Standard interfaces will be provided to connect regional and 
metropolitan networks and end devices. 


The network that will support all DoD data transport requirements is the Defense Information 
Systems Network (DISN), authorized under the Chairman of the Joint Chiefs of Staff (CJCS) 
Memorandum of Policy (MOP) 70, dated 5 February 1992. DISN is intended to support National 
Defense Command, Control, Communications, and Intelligence (C31) decision support 
requirements; Corporate Information Management (CIM) functional business areas; and Defense 
Information Infrastructure (DII) data processing and information transfer services. The DISN 
will support the DoD’s WAN on the global scale. DISN responsibility will extend to the local 
component in the future. 


2.4.2 Communications Models 


The geographically divided infrastructure described in Section 2.4.1 forms the foundation for an 
overal] communications framework. These geographic divisions permit the separate application 
Οἱ different management responsibilities, planning efforts, operational functions, and enabling 
technologies to be applied within each area. Hardware and software components and services 
fitted to the framework form the complete model. 


The following sections describe the OSI reference model and a grouping of the OSI layers that 
facilitates discussion of interoperability issues. 


2.4.2.1 The OSI Reference Model 


The OSI reference model, portrayed in Figure 2-10, is the model used for data communications in 
the TAFIM. Although DoD is no longer advocating the full use of OSI protocols, the OSI 
reference model is a valuable tool for conceptualizing networking requirements and solutions. 
Each of the seven layers in the model represents one or more services or protocols (a set of rules 
governing communications between systems), which define the functional operation of the 
communications between user and network elements. 


Each layer provides services for the layer above it. This model aims at establishing open systems 
operation and implies standards-based implementation. It strives to permit different systems to 
accomplish complete interoperability and quality of operation throughout the network. 


The seven layers of the OSI model are structured to facilitate independent development within 
each layer and to provide for changes independent of other layers. Stable international standard 
protocols in conformance with the OSI reference model layer definitions have been published by 
various standards organizations. Support and mission-area applications, as defined in the DoD 
Technical Reference Model, are above the OSI Reference Model protocol stack and use its 
services via the applications layer. 
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. Applications and application interfaces for OSI 
networks. Provides access to lower-layer functions 
Application and services. 
¢ Negotiates syntactic representations and performs data 
Layer 6 transformations (e.g., compression and code conversion.) 
Presentation | . . . 
¢ Coordinates connection and interaction between 
applications. Establishes a dialog, manages and 


Session synchronizes the direction of data flow. 


¢ Ensures end-to-end data transfer and integrity across 
Layer 4 the network. Assembles data packets for routing by 
Transport Layer 3. 


¢ Routes and relays data units across a network of nodes. 
Manages flow control and call establishment procedures. 


Layer 3 
Network 
ὁ Transfers data units from one network node to another 


Layer 2 over a transmission circuit. Ensures data integrity 
Data Link between nodes. 


Layer 1 ¢ Delimits and encodes the bits onto the physical medium. 
Physical Defines electrical, mechanical, and procedural formats. 


Figure 2-10. Open Systems Interconnection Model 


2.4.2.2 Communications Framework 


A communications system based on the OSI reference model includes services of all the layers 
described in the previous section plus the physical transmission media and the support and 
mission-area applications defined in Volume 2, Technical Reference Model. These elements 
may be grouped into architectural levels that represent major functional capabilities, such as 
switching and routing, data transfer, and the performance of applications. 


These architectural levels are: 


e The Transmission Level (below the OSI) provides all of the physical and electronic 
capabilities, which establish a transmission path between functional system elements (wires, 
leased circuits, interconnects, etc.). 


e The Network Switching Level (OSI layers 1 through 3) establishes connectivity through 
the network elements to support the routing and control of traffic (switches, controllers, 
network software, etc.). 


e The Data Exchange Level (OSI layers 4 through 7) accomplishes the transfer of 
information after the network has been established (end-to-end, user-to-user transfer) 
involving more capable processing elements (hosts, workstations, servers, etc.). 


e The Applications Program Level (above the OSI) includes the support and mission-area 
applications (non-management application programs). 
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The communications framework is defined to consist of the three geographical components of 
the DoD communications infrastructure (local, regional, and global) and the four architectural 
levels (transmission, network switching, data exchange, and application program), and is 
depicted in Figure 2-11. Communications services are performed at one or more of these 
architectural levels within the geographical components. 


Figure 2-11 shows computing elements (operating at the applications program level) with 
Supporting data exchange elements, linked with each other through various switching elements 
(Operating at the network level), each located within its respective geographical component. 
Figure 2-11 also identifies the relationship of the Technical Reference Model to the 
communication architecture. 


2.4.2.3 Allocation of Services to Components 


The DoD communications infrastructure consists of the local, regional, and global transport 
components. The services allocated to these components are identical to the services of the 
application program, data exchange, network switching, or transmission architectural levels that 
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Figure 2-11. Communications Framework 
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apply to ἃ component. Data exchange and network switching level services are identical to the 
services of the corresponding OSI reference model layers. Typically, only network switching and 
transmission services are allocated to the regional and global components, which consist of 
communications nodes and transmission media. All services may be performed in the local 
component, which includes end devices, processing nodes, communications nodes, and linking 
media. Transmission, switching, transport, and applications are all performed in this component. 


2.5 SECURITY VIEW 


The business of the DoD requires the controlled use of information. Security protection of DoD 
information systems is discussed in Volume 6 of the TAFIM, DoD Goal Security Architecture 
(DGSA). The purpose of this section is to provide a brief overview of Volume 6 with a focus on 
security protection implemented in the information system components. Doctrinal mechanisms, 
such as physical and personnel security procedures and policy, are discussed in Volume 6 but 
omitted here. 


Figure 2-12 depicts an abstract view of an information system architecture, which emphasizes the 
fact that an information system from the security perspective is either part of a local subscriber 
environment (LSE) or a communications network (CN). An LSE may be either fixed or mobile. 
The LSEs by definition are under the control of the using organization. In an open system 
distributed computing implementation, secure and nonsecure LSEs will interoperate. 


2.5.1 Basic Concepts 


This section presents basic concepts required for an understanding of information system security 
within DoD. 


2.5.1.1 Information Domains 


The concept of an information domain provides the basis for discussing security protection 
requirements. An information domain is defined as a set of users, their information objects, and 
a security policy. An information domain security policy is the statement of the criteria for 
membership in the information domain and the required protection of the information objects. 


Local Local 
Subscriber Subscriber 


Environment Environment 
(LSE) (LSE) 


*CN = Communications Network 


Figure 2-12. Abstract Security Architecture View 
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The missions of most DoD organizations require that their members operate in more than one 
information domain. The diversity of mission activities and the variation in perception of threats 
to the security of information will result in different information domains within one mission 
security policy. A specific mission may use several information domains, each with its own 
distinct information domain security policy. 


There must be no security-relevant distinction made among the information objects in an 
information domain. Members of an information domain may have different security-related 
attributes. For example, some members might have only read permission for information objects 
in an information domain, while other members might have both read and write permissions. 


Since all information objects in an information domain have the same security-relevant attributes, 
a user who has read and write permissions in an information domain has those permissions for 
every information object in the information domain. The term “information object” refers to any 
type of information. — 


Information domains are not bounded by information systems or even networks of systems. The 
security mechanisms implemented in information system components may be evaluated for their 
ability to meet the information domain security policies. 


2.5.1.2 Strict Isolation 


The strategy of “strict isolation” is used to isolate one information domain from another. 
Information objects can be transferred between two information domains only in accordance with 
established rules, conditions, and procedures expressed in the security policy of each information 
domain. Multidomain information objects may be defined for display or printing. A 
multidomain information object is a defined collection of information objects from multiple 
information domains. 


2.5.1.3 Absolute Protection 


The concept of “absolute protection” is used to provide a framework for achieving uniformity of 
protection in all information systems supporting a particular information domain. It directs 
attention to the problems created by the interconnection of LSEs that provide disparate strengths 
of security protection. This possibility is likely because open systems will consist of an 
unbounded number of unknown heterogeneous LSEs that must be able to interoperate. Analysis 
related to minimum assurance requirements will ensure that the concept of absolute protection 
will be achieved for each information domain across LSEs. 


2.5.2 Security Generic Architecture View 


Figure 2-13 shows the generic architectural view used in Volume 6 to discuss the allocation of 
security services and the implementation of security mechanisms. This view identifies the 
architectural components within a LSE. The LSEs are connected by CNs. The LSEs include end 
systems, relay systems, and local communications systems (LCSs), described below. 
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Figure 2-13. Generic Security Architecture View 


e Relay system — The component of an LSE, the functionality of which is limited to 
information transfer and 1s only indirectly accessible by users (e.g., router, switch, 
multiplexer, message transfer agent). It may have functionality similar to an end 
system, but an end user does not use it directly. Note that relay system functions may 
be provided in an end system. 


e Local communication system — A network that provides communications capabilities 
between LSEs or within a LSE with all of the components under control of a LSE. 


« Communication network -- A network that provides inter-LSE communications 
capabilities, but is not controlled by LSEs (e.g., commercial carriers). 


The ἐπα system and the relay system are viewed as requiring the same types of security 
protection. For this reason, a discussion of security protection in an end system generally also 
applies to a relay system. The security protections in an end system could occur in both the 
hardware and software. 


2.5.3 Security Services Allocation 


Security protection of an information system is provided by mechanisms implemented in the 
hardware and software of the system and by the use of doctrinal mechanisms. The mechanisms 
implemented in the system hardware and software.are concentrated in the end system or relay 
system. This focus for security protection is based on the open system, distributed computing 
approach for DoD information systems. This implies use of commercial common carriers and 
DoD-owned common-user communications systems as the CN provider between LSEs. Thus, 
for operation of end systems in a distributed environment, a greater degree of security protection 
can be assured from implementation of mechanisms in the end system or relay system. 
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However, CNs should satisfy the availability service to promote satisfaction of appropriate 
security protection for the information system. This means that CNs must provide an agreed 
level of responsiveness, continuity of service, and resistance to accidental and intentional threats 
to the communications service availability. 


End systems may not need to interoperate with others, but may need to accommodate multiple 
security domains processing simultaneously. 


Implementing the necessary security protection in the end system occurs in three system service 
areas. They are operating system services, network services, and system management services. 


Most of the implementation of security protection is expected to occur in software. The 
hardware is expected to protect the integrity of the end system software. Hardware security 
mechanisms include protection against tampering, undesired emanations, and cryptography. 


2.5.3.1 Operating System Services 


A “security context” is defined as a controlled process space subject to an information domain 
security policy. The security context is therefore analogous to a common operating system 
notion of user process space. Isolation of security contexts is required. Security contexts are 
required for all applications (e.g., end user and security management applications). The focus is 
on Strict isolation of information domains, management of end system resources, and controlled 
sharing and transfer of information among information domains. Security-critical functions are 
isolated into relatively small modules that are related in well-defined ways. 


The operating system “separation kernel” will maintain the required isolation. The separation 
kernel will use the protection features of the end system hardware (e.g., processor state register, 
memory mapping registers) to maintain strict separation among security contexts by creating 
separate address spaces for each of them. Untrusted software will use end system resources only 
by invoking security-critical functions through the separation kernel. Security-critical functions 
perform inter-security context (i.e., inter-information domain) operations. Most of the 
security-critical functions are the low-level functions of traditional operating systems. 


2.5.3.2 Network Services 


Two basic classes of communications are envisioned for which distributed security contexts may 
need to be established. These are interactive and staged (store and forward) communications. 


The concept of a “security association” forms an interactive distributed security context. A 
security association is defined as the totality of communication and security mechanisms and 
functions to extend the protections required by an information domain security policy within an 
end system to information in transfer between multiple end systems. The security association is 
an extension or expansion of an OSI application layer association. An application layer 
association is composed of appropriate application layer functions and protocols plus all of πε. 
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underlying communications functions and protocols at other layers of the OSI model. Multiple 
security protocols may be included in a single security association to provide for a combination 
of security services. However, a security association can only be established within the same 
information domain: inter-information- domain security associations are not allowed. 


For staged delivery communications (e.g., e-mail), use will be made of an encapsulation 
technique (termed “wrapping process”) to convey the necessary security attributes with the data 
being transferred as part of the network services. The wrapped security attributes are intended to 
permit the receiving end system to establish the necessary security context for processing the 
transferred data. If the wrapping process cannot provide all the necessary security protection, 
interactive security contexts between end systems will have to be used to ensure the secure staged 
transfer of information. 


2.5.3.3 System Security Management Services 


Security management is a particular instance of general information system management 
functions as discussed in Volume 2. Information system security management services are 
concerned with the installation, maintenance, and enforcement of information domain and 
information system security policy rules in the information system intended to provide these 
security services. In particular, the security management function controls information needed by 
operating system services within the end system security architecture. In addition to these core 
services, security management requires event handling, auditing, and recovery. Standardization 
of security management functions, data structures, and protocols will enable interoperation of 
security management application processes (SMAPs) across many platforms in support of 
distributed security management. Areas for security management standardization are described 
in Volume 6, DoD Goal Security Architecture (DGSA). 


SMAPs, using information in the information base, will be used to establish the required security 
contexts for interactive communications among distributed platforms operating in various 
information domains simultaneously. System SMAPs will also be used to provide the security 
protection of store-and-forward communications in which the requisite security contexts cannot 
be handled within the message. The end system will establish a security association by using a 
SMAP, a security association management protocol (SAMP), and information in the security 
management information base (SMIB). Figure 2-14 shows the general relationship of the 
processes and protocols involved in establishing a security association for interactive 
communications among distributed end systems. 
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3.0 DESIGN GUIDANCE 


The architectural concepts discussed in Section 2 are needed to realize the long-term DoD IM 
vision of an open distributed computing environment. In the near term, new information 
systems will be engineered and integrated into an environment that includes legacy and 
migration systems. Many legacy and migration systems use non-standard and proprietary 
approaches. This complicates the integration of new systems designed for an open systems 
environment. This chapter focuses on near-term application of the architecture concepts. It 
includes guidance for integrating open systems, legacy systems, and migration environments. 
The guidance presented in this section will evolve over time based on the availability and 
maturity of technology. The guidance in this section supplements the concepts in Volume 2. 


3.1 GUIDANCE FOR DESIGNING ARCHITECTURES 


An architecture is a set of components and a specification of how these components are 
connected to meet the overall! requirements of an information system. The components of an 
architecture provide implementations of the reference model services relevant to a specific 
system. The following are guidelines for designing specific architectures given the Technical 
Reference Model and the model of information system architecture: 


e An architecture will contain components to implement only those reference model 
services that it requires. 


e Components may implement one, more than one, or only part of a service identified in 
the reference model. 


e The components should conform to the profile standards that are relevant to the 
services they do implement. 


The following is a general procedure for designing a specific architecture given the guidelines 
above: 


e Perform requirements analysis 
e Make service allocations 
e Select components 


e Evaluate. 


3.2 COMPUTING MODELS 


This section presents guidance on the computing models discussed in Section 2.2. 
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3.2.1 Client/Server Model Design Analysis and Guidance 


The objective computing environment 15 a distributed computing environment based on open 
systems principles and public standards (e.g., Federal Information Processing Standards [FIPS] 
and ISO). In this environment, services will be provided by servers distributed to processing 
nodes throughout a network. Services will be distributed based on attention to survivability, 
efficiency, and functional requirements. As DoD migrates to a distributed computing 
environment, many different types of client/server capabilities will be established. These will 
support, among other things, the initial implementation of subject area databases, access to data 
managed by migration systems from open system platforms, and interactive applications that are 
distributed to a POSIX platform and accessed via a standards-compliant graphical user interface 
(GUI). The following are some guidelines related to the client/server model: 


e Provide client processes with a high-level interface with as few details about the 
underlying communication and processing details as possible. An example interface is 
that provided by the CORBA. Design the client/server mechanism so that the location 
of the server can change without impacting the client application. 


e Isolate the client application from the details of the interprocess application. This 
would allow details of the communication mechanism to change without affecting the 
client application. This would also allow requests for services to be provided by both 
local and remote servers, and the client would be insulated from the details. 


e Design subject area databases to provide users and client processes with the capability 
to query data without knowing where or how the data is physically stored. Use 
distributed processes to provide record level access to mainframe migration databases. 
Until products are readily available that comply with an open standard, the preferred 
method 15 through a de facto standards-based implementation of the client/server 
model. This will require implementation of a de facto standard on the appropriate 
mainframe platform. End-user workstations that require this type of access will also 
require a de facto standard implementation. This will give distributed users and client 
processes access to both query and update data managed by migration mainframe 
databases. 


e Use other implementations of the client/server model achievable today, including 
access to file and print servers provided through a network file service. This can 
provide users with remote access to files and network printers. These services should 
be provided in such a way that there is a migration path to open standards when they 
become available. | 


To summarize, the client/server model provides a flexible framework for designing and 
maintaining distributed processing applications. New application-enabling technology, such as 
computer-aided software engineering (CASE) and GUIs, focus on this model. Some general 
advantages of the model are: 
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e Readily supports the open systems concepts of portability, interoperability, scalability, ᾿ 
modularity, and flexibility 


e Allows for the continued use of existing capital investments such as PCs, LANs, 
minicomputers, and mainframes 


e Enables data sharing among many different applications 


e Accommodates special function hardware or software that does not have to be 
duplicated 


e Allows data and processing to be distributed to the appropriate organizational level 
e Supports centralized control and security of data 


e Supports survivability through the management and distribution of redundant data and 
processes 


e Supports consistent user interfaces across applications. 


3.2.1.1 Guidance on the Multitiered Architecture 


Industry evolved from single-tiered architectures on mainframes to two-tiered architectures 
(often still on mainframes) because there was a recognized need to separate data from 
applications. In the single-tier architecture, each application had its own data in its own files and 
there was little, if any, opportunity for application A to share application B’s data. Once the data 
was separated from the applications, which has often happened in actual implementations of the 
two-tiered client/server architecture, the data became a resource that could be used across 
multiple applications. Inconsistent data sets were eliminated (in concept at least), concurrent 
access to data was allowed, integrity constraints on data were supported, and data was protected. 


The multitiered approach is an extension of the two-tiered approach. By now separating the user 
interface (1.e., the presentation layer) from the rest of the application (remember, data has 
already been separated out), the functional code of the application can be turned into the 
elements of a reusable library of functional routines. Furthermore, those routines can begin to 
be executed on networked platforms (possibly remote from the user platform); the elements of 
the presentation layer can also be turned into a library of reusable elements, and the user 
interface can be replaced with a new interface without having to rewrite the entire application. 


The multitiered approach will allow migration of legacy systems to modular systems and taking 
advantage of the benefits mentioned above. However, the separation of the application logic and 
presentation layers may exclude certain COTS systems that would otherwise offer significant 
benefits — in particular, there are COTS products (two-tier) that offer the benefit of porting their 
clients to multiple platforms with a simple recompilation. There are also products (again two- 
tier) that offer very powerful data access and manipulation capabilities across multiple data 
servers (like cross-database joins) that would otherwise have to be coded and maintained as part 
of the “functional” code. 
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New system and migration system architectures should carefully consider the relative advantages 
of specific COTS products as well as the two-tiered and multitiered approaches based on the 
specific system’s requirements. No single solution will meet the needs of all DoD systems. 


3.2.2 Guidance for Other Computing Models 


The compelling advantages of the client/server model must be weighed against many potential 
disadvantages. The requirements of some environments cannot withstand the potential 
disadvantages of a migration to client/server in the near term. When considering migration from 
a centralized or mainframe environment, the following disadvantages of the client/server model 
should be considered: 


e Client/server computing is heavily dependent upon the reliability and performance 
characteristics of the network. 


e Security and data integrity requirements are more complicated than when processing 1s 
performed on a single (e.g., mainframe) platform. Access to servers and services must 
be limited to authorized clients. Each client also must be able to select a specific server 
and be assured that only this server gets access to its data during callbacks. The sender 
of messages must be assured that messages are neither read nor distorted by other 
parties. A secure message requires an authentication service and an encryption 
technique. The message protocol must be able to support the needed security services 
as determined at runtime. 


e Client/server implementations usually entail! the integration of a more diverse set of 
products (than for mainframe-based implementations), increasing the integration effort, 
complexity, and risk. 


e System management, administration, performance monitoring, fault isolation, and 
correction are more difficult. This is due principally to a lack of tools, a more complex 
environment, and the interaction of diverse components. 


e Development and maintenance staffs that have been working in mainframe 
environments often do not possess the necessary skills to implement and maintain 
client/server systems. 


e The expected cost saving through the use of low-cost commodity processors may be 
offset by increased administration costs and the need for highly qualified support 
personnel. 


e Initial client/server implementations often take longer and cost more than expected due 
to lack of familiarity with the development process and tools. 
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Φ [{|5 difficult to replicate problems at a vendor or other central support site. 
Client/server systems are often a combination of COTS products, protocols, local 
configuration parameters, and developed software that result in a system with many 
unique attributes. 


e The security implications are not as well understood in comparison with those for 
mainframe solutions. 


When several of these disadvantages are concerns, a client/server implementation may not be the 
best solution. A mainframe-based approach such as the master-slave or three-tiered model may 
be more appropriate. 


With respect to other models, the following considerations should be addressed. The 
peer-to-peer approach 15 often considered a superior alternative to the client/server approach, 
providing client/server capabilities with the advantage that an application can be processed on 
any computer in the network — wherever the computing resources are available. However, there 
are technical challenges associated with the peer-to-peer model that have not been overcome to 
date, and very few implementations of this model are commercially available. The major value 
of this type of design approach is that it enhances system availability. This approach could be 
used to provide system availability for implementations of other computing models. It could 
provide a hot standby for a centralized system or hot standbys for servers in a client/server 
implementation. Some types of servers that would benefit from redundancy are naming, 
communications, and database. 


The distributed object management model can be considered as a special case for the 
client/server or peer-to-peer model, and some consider it superior to the client/server model 
because of its attempt to provide a cleaner, simpler interface between systems. This model 
significantly reduces the number of interfaces required among interoperating platforms. It 
requires only one interface for all platforms as opposed to one interface for each pair of 
platforms. This ts a significant advantage. In addition, once a system has sent a message to 
another system, the sending system is not required to cease all processing while awaiting a 
response. 


3.3 DATA MANAGEMENT 


The near-term goals for improving data management in the DoD are focused on consolidation 
and interoperation. Consolidation is being carried out primarily in the context of existing 
applications, resulting in the need to merge databases of similar applications into a single 
migration system. The surviving system will not necessarily be upgraded to meet target 
architectural standards. As a result, many existing data management technologies will still be in 
use at the end of the near-term period. Longer term, the strategic combination of data 
management components and the standards in Volume 2 of the TAFIM will allow DoD to 
evolve to an open systems environment. This can be achieved through the identification of 
flexible data management components and the implementation of systems intended to enhance 
DoD-wide interoperability. 
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3.3.1 Guidance on DBMSs 


The alternative to a DBMS 1s a flat file system. The primary advantages of a DBMS are data 
independence and controlled redundancy. In addition, DBMSs provide capabilities for defining 
a database through a schema, querying and manipulating the data, concurrency control, and 
systematic backup and recovery. Flat file systems provide none of these capabilities. A DBMS 
is preferable to a flat file system. 


Flat files might be chosen over DBMSs in the rare event that the application and the file require 
a very high level of performance (a flat file system does not carry the overhead burden of a 
DBMS) and very little maintenance. 


3.3.1.1 Guidance on Database Models 


The RDBMS has become the DBMS of choice over the hierarchical and network model DBMSs. 
There are several reasons for this. Because of the complexity of the structures involved in the 
hierarchical and network models, the manner of accessing the data, and the implementation of 
the structures, both the hierarchical and network models are considered significantly more 
difficult to manage than the relational model. With the hierarchical and network DBMSs, the 
application programmer must specify the navigation path for reaching data, e.g., the complete 
hierarchical path for reaching a data item, as opposed to just the attribute name in the case of an 
RDBMS. In addition, physica! pointers are used in hierarchical and network DBMSs to 
represent the parent-child and owner-member relationships, respectively. These physical 
pointers present a difficult challenge in pointer maintenance. The tabular representation of data 
in the relational model and the relational algebra and calculus languages used to interact with 
relational databases are considered much simpler than network and hierarchical systems, and 
application programming and maintenance are much easier. In addition, the performance 
problems of the early RDBMSs have been overcome, and it has been shown that data that can be 
modeled as hierarchies and networks can also be modeled as relations. Therefore the RDBMS is 
recommended over the network and hierarchical DBMSs. 


Many experts say we are at the beginning of a new generation of DBMSs - the object-oriented 
and extended relational. An extended relational DBMS is a relational DBMS with some 
object-oriented features, generally class inheritance, complex data, or large objects (such as text 
and graphics). RDBMSs are excellent for conventional or business data, such as personnel and 
payroll, but not for non-conventional data and applications. Examples of applications requiring 
non-conventional data are CASE, computer-aided design (CAD), computer-aided manufacturing 
(CAM), and expert systems. These new applications require multiple data types and the ability 
to represent complex relationships among the data. In addition, the new applications require 
modeling power, long and design transactions, and version and configuration management. 
OODBMSs are being designed and manufactured to meet these needs. A criticism of OODBMSs 
is that they are reminiscent of network DBMSs with their pointers to implement relationships. 
However, OODBMSs use logical, not physical pointers, and the difficulty of pointer 
maintenance present in network DBMSs does not apply to OODBMSs. Another criticism of 
OODBMSs is that there is no formal theory behind the model, as with the relational model. 
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However, there are formalisms involved, such as generalization (class/subclass/inheritance), 
aperegation (objects composed of other objects), and object identity. Standards are not final in 
this area, and as such the OODBMS presents some risk (e.g., in portability). 


OODBMSs fill a gap in the data management area with respect to non-conventional applications 
that are becoming more prevalent. Most of the commercial OODBMS products are oriented to 
client/server environments. Procurement of an OODBMS is recommended when the need to 
support non-conventional applications 1s present. 


3.3.1.2 Guidance on Distributed DBMSs 


Replicated databases are recommended when survivability, availability, low transmission cost, 
and quick response time are important. Replicated databases enhance survivability because if 
one copy is destroyed in a disaster, other copies are available at other locations. Availability 15 
enhanced for similar reasons. Replicated copies can be located close to the users, so 
transmission costs are less. For the same reason, response time should be less. 


A disadvantage of fully synchronized replicated databases is that updates are expensive because 
of the need to maintain complete consistency between copies of the database. This form of 
replication can also result in the inability to update the database if one of the copies 15 
unavailable due to network or system problems. Therefore this form of replication is not 
recommended when there are frequent database updates. The use of delayed replication servers 
is recommended except in the rare cases where absolute consistency is required. 


A disadvantage of replicated databases is that updates are expensive because of the need to 
synchronize the updates of the copies of the database. Therefore, this distributed DBMS 
approach is not recommended when there are frequent database updates. 


Partitioned databases are recommended when: 1) there is a high locality of reference — data at a 
site is used most by local users and infrequently by remote users; 2) retrieval costs are a concern 
— these costs are lower; and 3) update costs are a concern — these costs are also lower. 


3.3.1.3 Guidance on Distributed Heterogeneous DBMSs 


Many DBMSs provide gateways to databases managed by other DBMSs. Gateways are 
recommended when an organization has standardized on one DBMS, but there 15 other data, 
either legacy or in another organization, that the organization needs to access. Gateways are 
generally limited — that is from one DBMS to one or two other DBMSs without a general 
solution to federating databases. Gateways are usually an option when procuring a DBMS (e.g., 
a gateway to DB2 when Sybase RDBMS 1s purchased). Gateways are recommended when there 
is a specific need to access a second DBMS using the organization’s standard DBMS. 


Federated database systems are usually sold by third parties for use 1n integrating databases 
managed by different vendor DBMSs. For example, a federated database product might be sold 
that integrates relational, hierarchical, network, and object-oriented DBMSs. These products 
attempt to present a general solution for integrating data. Typically, a common data model (e.g., 
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entity-relationship, object-oriented, or relational) is used to develop schemas of the shared data 
from all the databases. A user sees schemas or views in this common data model and accesses 
any participating database using the common data language that is provided. In this approach a 
user is not burdened with having to know the data models and languages of all the participating 
DBMSs. Federated database systems are an acknowledgment that different autonomous groups 
often make different decisions on which data model (e.g., relational versus object-oriented) or 
DBMS to use. Yet the results of the different choices may well have to interoperate. This 
applies to integrating legacy and migration databases, as well as the integration of different open 
system databases. Federated database systems are recommended for the interoperability of 
autonomous database systems — legacy, migration, and open. 


3.3.2 Guidance on Data Dictionary/Directory Systems 


All DBMSs procured should include an integrated DD/DS. 


3.3.3 Guidance on Data Administration 


The 8320 series of DoDD provides detailed guidance on data administration. 


3.3.4 Guidance on Data Security 


Commercially available data management components typically provide integrity and 
availability services. The integrity services are used to maintain internal database consistency, 
while availability services control concurrent access to database resources. Some degree of 
identity-based confidentiality protection is also provided by being able to specify the data 
management commands that certain users are allowed to execute with respect to certain database 
objects. To protect the confidentiality of classified or unclassified-but-sensitive data, use of a 
trusted database management system may be recommended. 


DBMSs that have undergone the National Computer Security Center (NCSC) evaluation process 
are recommended for secure environments. It is important to note that the NCSC evaluates 
DBMSs based on their ability to enforce a defined confidentiality policy. Enforcement of an 
integrity and availability policy is not part of the current evaluation requirements, although the 
National Institute of Standards and Technology (NIST) test suite for compliance with the 
American National Standards Institute (ANSI) SQL standard does test for the support for those 
features that are part of the current ANSI SQL standard. Since the evaluation of trusted DBMSs 
is a new procedure, additional guidance in this area may be forthcoming. 


In the near term, several options exist: Treat the database management system as an untrusted 
component operating on a trusted operating system; begin utilization of relational database 
management systems that are in the evaluation process, while supplementing systems with other 
controls to compensate for the low assurance rating; or begin using a combination of trusted 
database management system and trusted operating system capabilities to achieve higher 
assurance for label-based confidentiality policy. The first approach allows the application to use 
the full suite of commercial software but does not provide support for needed security 
functionality. The other two approaches provide confidentiality support to various levels of 
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assurance but may require a sacrifice of application functionality because the full suite of 
commercial software may not be compatible with the selected trusted products. 


Use of client/server architectures in a distributed configuration for data management functions is 
highly appropriate but may not be fully supported by the current suite of trusted database 
management system products. In addition, these systems provide limited or no support for 
distributed data management functions with enforcement of confidentiality. If the data 
management capability does support operation in a distributed configuration, the other non-data- 
management components must also be considered. This is required because the point of exposure 
to security vulnerability involves each system component and the communication system, since 
requests and responses must be protected as they travel through the distributed system. 


3.3.5 Transition Components 


In the environment of the future, there will be a DoD information architecture with standardized 
components and local nonstandard systems. The data architecture will include the DoD data 
model, standard database structures, standard data elements, and procedures. The current 
environment of legacy systems will need to migrate to the new environment. In transitioning to 
this new environment, many of the data management components discussed in Section 2.2 will 
be used. In the near future, RDBMSs will begin to proliferate. Database gateways and federated 
systems will exist to link the RDBMSs with legacy data in flat files and hierarchical and network 
databases. Some OODBMSs will begin to appear, and federated systems will also link them 
with the RDBMSs and legacy systems. Distributed DBMSs will be used to provide 
survivability, availability, and the placement of data closer to the users. 


3.4 COMMUNICATIONS 


The DISN will evolve to become the common, worldwide communications infrastructure. It 
will provide integrated data, voice, video, and imagery services with connectivity for command 
and control systems, intelligence systems, and business systems. In the future, DISN will provide 
consolidated communications services that efficiently satisfy DoD connectivity requirements. 


The DISN will provide or facilitate the following capabilities: 


e User logon to any number of computers from any number of locations 
e Communications at all levels of classification 


e Support to real world events as users change locations and network nodes and end 
devices change locations 


e Dynamic network management to ensure that essential communications receive 
priority, that the network adjusts to the addition or deletion of communications nodes 
and links, and that messages are routed to intended recipients regardless of their actual 
location 
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e Connectivity or gateways to other federal communications networks and commercial 
networks ‘ 


e Mobile communications on land, in the air, or at sea that will incorporate wireless 
service to extend connectivity to mobile users 


e Military-unique requirements, including precedence and preemption 
e Linkages to civil and commercial elements 


e Theater communications that may be rapidly deployed, robust, and reliable, and that 
support all the military-unique requirements. 


3.4.1 Communications Design Guidance 


The following guidance 1s provided on communications: 


e All communications requirements will be fulfilled using communications services and 
networks that adhere to the DISN architecture and the guidance provided in TAFIM 
Volume 2. 


e Communications systems will provide compatibility with the Defense Message System 
(DMS). 


e Where it is consistent with functional requirements, information systems will rely on 
DISN rather than providing their own communications capability. 


3.4.2 Transition Elements 


The current global communications network is a loosely connected collection of legacy and 
migration systems. In the near term, transition elements, such as application and network 
gateways, will provide greater connectivity and increased availability. In the mid to long term, 
transition elements will be phased out as all networks adopt accepted open systems elements. 
For the foreseeable future, the global communications network will remain a network of 
networks. The communications network will appear to be global. However, it will actually 
consist of a large number of smaller networks interconnected by gateways. 


3.4.2.1 Multiple Protocol Networks 


In a network of networks configuration, terminals, personal computers, and workstations will be 
directly connected to a local area network. The local area networks will be connected via a 
gateway to a metropolitan, regional, or wide area network. The metropolitan, regional, or wide 
area networks provide connectivity with other local area networks. In the near term, it is likely 
that many of these devices will use different communication protocols. Connectivity can be 
accomplished with multiple protocol networks. The multiple protocol network should not, 
however, be viewed as a long-term architectural solution. It provides connectivity directly 
among local networks with compatible protocol profiles but does not necessarily provide 
interoperability between local networks. 
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3.4.2.2 Techniques for Achieving Interoperability 


Many existing systems are designed with proprietary protocols (e.g., IBM’s prevalent System 
Network Architecture [SNA]). Bringing such systems into compliance with accepted open 
systems standards to achieve systemwide interoperability may be accomplished in several ways. 
Methods of achieving interoperability between different protocol systems include: 


e Total Adoption — Changing all elements throughout the system at all architectural 
levels defined in Section 2 to operate with the specified standard protocol set (i.e., 
making the standard “native’’). 


e Conversion/Application Gateway — Employing a gateway as an interface between 
two disparate network protocols to convert one to the other (e.g., IBM’s SNA to 
TCP/IP). The gateway process involves performing all the functions of each protocol 
set (from the Network Switching through the Application Program levels) to retrieve 
the original application layer data and commands and then reintroducing it to the 
second protocol set. The application gateway is described further in Section 3.4.2.3. 


e Adaptation — Substituting a different set of top layer protocols to ride on a lower layer 
standard (e.g., selecting a application set other than Telnet, File Transfer Protocol 
(FTP), or Simple Mail Transfer Protocol (SMTP) to work with TCP/IP). The process 
would incorporate several upper level protocol sets at a single processing location. It 
permits transmission with existing lower level protocols but with different Application 
layer protocols. 


e Multiple Stacks — Equipping processors (workstations, servers, or mainframes) with 
several complete protocol sets. This gives the user the ability to enter all networks for 
which the processor retains a compatible protocol. 


e Encapsulation — Wrapping the carrying protocol around the original protocol (e.g., 
TCP/IP wrapped around SNA) may be performed by a router. Encapsulation allows 
the carrying protocol to appear transparent (the original protocol enters and exits a 
network unaltered), permitting the original network elements to continue to operate 
without alteration. 


3.4.2.3 Application Gateways 


Application gateways may be used as a transition solution for the interconnection of two 
networks that adhere to different sets of standards. For example, application gateways could be 
used to connect a legacy network that supports military standard protocols to a network that is 
compliant with accepted open systems protocols. The gateway machine would be connected to 
both communications networks and support different connections on each end to enable the 
transfer of files. Applications that need to transfer files between the networks would use this 
application gateway and the gateway machine. 
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Application gateways are not beyond the current state of technology. There are platforms that 
have software installed to allow access by multiple protocols. For example, there are platforms 
that allow both FTAM and FTP access and others that support multiple protocols of electronic 
mail or messages. 


Application gateways are not a solution and are not available for all application areas. If the 
protocols of the two applications are not sufficiently similar, the application gateway will not be 
viable. It will not be able to offer the functionality and robustness required. If either of the two 
applications does not have a significant market share, vendors will be hesitant to build an 
application gateway. That is, the gateway will not be commercially available. 


3.4.2.4 Network Gateways 


The global network will be made up of networks or communications links based on many 
different technologies. There will be links that are based on radio waves, optical beams, and 
fiber, coaxial, and copper cables. Communications is accomplished or optimized by using 
protocols that are uniquely matched to the network’s or link’s technology. The network gateway 
operates at the Network Switching level and is used to create the connection between links or 
networks based on different Network Switching level protocols. Thus, the network gateway is 
used to permit the compatible use of various technologies in the Transmission and Network 
Switching levels rather than facilitate Application level interoperability. 


The network gateway performs packet translation. A number of protocols, which adhere to 

de jure and de facto standards, are based on a data packet. The network gateway understands 
how each of the protocols positions data within the packet. As it moves the packet from the 
source network to the destination network, it translates the data within the packet. Hence, each 
network only receives packets of the expected format. Network gateways that interconnect 
networks of different technologies and perform translation are viable and commercially 
available. 


3.5 SECURITY PROTECTION GUIDANCE 


3.5.1 Introduction 


Volume 6 provides guidance to information system designers and implementors in the form of 
security principles and target security capabilities. The intent of this section is to provide a brief 
overview of selected guidance highlights of Volume 6 for individuals who are not information 
system security specialists. This section also contains two tables with general information about 
location of security services in the various OSI layer protocols and about appropriate 
mechanisms used to provide required security services. The source of these two tables is ISO 
7498-2. 


The guidance in Volume 6 is general because various mechanisms or combinations of 
mechanisms or services may be used or necessary to satisfy the requirements of the security 
policy for the information domain(s) handled in any particular information system. A wide 
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variety of specific implementations, dictated by mission and threats, will be needed. The 
information system designer and implementor will need to work with the designated approving 
authority of the information system to identify the required level of protection and suitable 
mechanisms and services. In addition to mechanisms that may be implemented in the hardware 
and software of the information system, mechanisms that are doctrinal (i.e., physical, 
administrative, and personnel) will also be used to achieve the necessary level of security 
protection for the information domains handled by the information system. 


The following factors should be considered in determining appropriate security mechanisms: 
e Strength of security mechanisms 

e Characteristics of security mechanisms 

e Cost of security mechanisms 

e Performance penalties. 


As described in Section 2.5, implementation of security services and mechanisms may be 
allocated to the various components within a LSE and to the CN. The guidance focuses on 
implementation of security service mechanisms in end systems (or relay systems). Since end 
systems and relay systems are viewed as requiring the same kinds of security protection, 
guidance pertaining to an end system generally also applies to a relay system. The security 
protection provided in an end system will be implemented in both the hardware and software. 


A minimum assurance analysis should be performed to satisfy the requirements of absolute 
protection as defined in Volume 6. 


3.5.2 Guidance for End Systems and Relay Systems 


A variety of choices exist for implementations of security mechanisms between the hardware 
and software portions of an end system or relay system. 


3.5.2.1 Hardware Guidance 
Implementations in hardware should: 


e Enforce isolation of software functions by use of protected paths between users and 
applications and between application functions 


e Ensure software and hardware integrity by use of anti-tampering and unwanted 
radiation devices/techniques 


e Ensure availability by use of fault tolerant and fault detecting architectures. 


Cryptographic mechanisms should be used for maintaining strict isolation for information in 
transfer between end systems. The cryptographic devices should be sufficiently flexible to 
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support requirements of different information domains. It may be necessary to use multiple 
cryptographic devices. 


3.5.2.2 Software Guidance 


A software architecture built around trusted and untrusted software components is 
recommended. Trusted software should be used for security-critical functions, including 
exchanges between information domains. Trusted software must be evaluated and maintained 
under strict configuration management. Untrusted software should only be able to invoke 
functions through the use of trusted software. Nonetheless, it is recommended that untrusted 
software be obtained from reliable sources, tested before use, and be subjected to integrity 
safeguards to preclude its modification. Configuration management should also be applied to it. 
Security protection 1s provided for guidance in three service areas of the end system software: 


e Operating system services 
e Network services 


e System management services. 


3.5.2.2.1 Operating System Services 


The recommended end system security architecture relies upon an engineering approach that 
seeks to isolate security-critical functions into relatively small modules that are related in well- 
defined ways. Security-critical functions should generally provide commonly used, low-level 
operating system functions. This is considered consistent with commercial operation system 
vendors’ design and implementation strategies. Volume 6 identifies some security-critical 
functions. Prototyping and experimentation is also needed to identify other software functions 
that need to be handled as security-critical. 


3.5.2.2.2 Network Services 


Communications protocols are to be used for implementing security protection mechanisms for 
inter-end-system information transfers within the same information domain. The allocation of 
security services to the various OSI layers is shown in Figure 3-1. As shown, no security 
services are allocated to OSI layer 5, and no specific services are allocated to layer 6. It also 
needs to be noted that all services are allocated for possible implementation in OSI layer 7, the 
application layer. However, the implementation may not be in OSI layer 7, but rather in the 
application process using the communications services. Details of the rationale for allocation of 
the security services to the OSI layers are contained in ISO 7498-2. Security protocols relevant 
to the layers shown in Figure 3-1 are given in Volumes 6 and 7. 


Some lower layer security protocols can multiplex several security associations between the 
same end systems. It is not expected, however, that multiplexing for information systems 
handling different information domains simultaneously will be acceptable to a designated 
approving authority. 
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* No services are allocated to OSI layer 5: layer 6, the presentation layer, contains a number of security facilities 
which support the provision of security services by the application layer. 

** The services allocated to OSI layer 7, the application layer, may be provided by the application process itself. 
N = Service not allocated to layer. 

Y = Service allocated and should be provided for in layer protocol. 

NOTE: This table needs to be revised to reflect pending changes to ISO 7498-2. This revision will be 
accomplished when the source information is finalized and analyzed. 


Figure 3-1. Security Services Allocated to OSI Layers* 


3.5.2.2.3 System Management Services 


A security management application process should be used for establishing a security association 
for interactive communications among end systems. Implementation of communications 
applications (e.g., X.400 electronic mail, X.500 directory services, file transfer) and 
communications protocols will occur as untrusted applications within the end system software 
security architecture. Security protection for these untrusted applications should be provided by 
the establishment of a security association for an interactive communications dialog. A SMAP 
should be used to establish a security association. 
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End systems that support multiple information domains must also provide independent security 
management for each of the information domains. The security policy rules for both end system 
security management and information domain security management must be part of the end 
system security management information base. The relationship between the SMIB and a 
SMAP ts described in Volume 6. The SMAP must be capable of responding to an end user 
application request for a specific security mechanism or be able to adopt a suitable one based on 
the information domain or end system security policies contained in the SMIB. 


To allow for effective distribution of security management across many end system platforms, 
standardization of security management functions, data structures, and protocols is 
recommended. Specific areas for security management standardization are identified in 
Volume 6. 


3.5.3 Guidance for Architectural Components Other Than End Systems or Relay Systems 


This section provides a brief overview of the guidance in Volume 6 for the architectural 
components of local subscriber environment, local communications system, and communications 
network. 


3.5.3.1 Local Communications System Guidance 


Security services are generally not required of implementations in the LCS unless the LCS is 
only used for communications among end systems in the same LSE. Even if this condition is 
satisfied, care must be taken that implementations in the LCS do not interfere with requirement 
added at a later date for communications with end systems in other LSEs. Nonetheless, should 
implementations of security mechanisms in the LCS be desirable, use of the same approaches 
(protocols and security management applications) as described for the end system network 
services will apply. 


3.5.3.2 Communications Network Guidance 


Because of the use of common carriers for transmitting information, the CNs are expected 
frequently not to be under the control of the DoD, and perhaps not under the control of a DoD 
organization with a comparable or otherwise suitable DoD information domain security policy. 
Therefore, allocating security services other than availability to the CNs is not recommended. In 
addition to the general need for communications resource availability, this may also provide for 
protection against “denial of service” to specific applications. 
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ACRONYMS AND DEFINITIONS 


ACRONYMS 


Automated Information System 
American National Standards Institute 
Application Program Interface 
Application Portability Profile 


Bulletin Board System 


Command, Control, Communications, and Intelligence 
Computer-Aided Design 

Computer-Aided Manufacturing 

Computer-Aided Software Engineering (See ISEE) 
Corporate Information Management 

Chairman of the Joint Chiefs of Staff 
Communications Network 

Common Object Request Broker Architecture 
Commercial-Off-the-Shelf 

Conference on Data Systems Languages 


Database Management System 

Data Dictionary/Directory System 
Defense Goal Security Architecture 
Defense Information Systems Agency 
Defense Message System 

Department of Defense 

Department of Defense Directive 
Defense Information Systems Network 


Electronic Mail 
External Environment Interface 


End System 


Federal Information Processing Standard 
File Transfer, Access, and Management 
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LAN 
LCS 
Poe 


MAN 
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MIL-STD 
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NIST 
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OODBMS 
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OSI 

OMG 


POSIT 
POSIX 
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File Transfer Protocol 


Government Open System Interconnection Profile 
General Security Service 
Graphical User Interface 


International Business Machines 

Internet Engineering Task Force 

Information Management 

Information Resource Dictionary System 

Indexed Sequential Access Method 

International Organization for Standardization 

Information Technology 

Information Technology Standards Information Bulletin Board System 


Joint Interoperability and Engineering Organization 


Local Area Network 
Local Communications System 
Local Subscriber Environment 


Metropolitan Area Network 
Message Handling System 
Military Standard 
Memorandum of Policy 


National Computer Security Center 
National Institute of Standards and Technology 


Object Linking and Embedding 
Object-Oriented Database Management System 
Object Request Broker 

Open System Interconnection 

Object Management Group 


Profiles for Open Systems Internetworking Technologies 
Portable Operating System Interface (for Computer Environments) 


Relational Database Management System 
Relay System 
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Security Association Management Protocol 
Security Management Application Process 
Security Management Information Base 
Simple Mail Transfer Protocol 

System Network Architecture 

Structured Query Language 

Special Working Group 


Technical Architecture Framework for Information Management 
Transmission Control Protocol/Internet Protocol 
Technical Reference Model 


Wide Area Network 
World Wide Web 
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DEFINITIONS 


Application—The use of capabilities (services and facilities) provided by an information system 
specific to the satisfaction of a set of user requirements. [P1003.0/D15] 


Application Platform-The collection of hardware and software components that provide the 
services used by support and mission-specific software applications. 


Application Portability Profile (APP)-The structure that integrates Federal, national, 
international, and other specifications to provide the functionality necessary to accommodate the 
broad range of federal information technology requirements. [APP] 


Application Program Interface (API)-(1) The interface, or set of functions, between the 
application software and the application platform. [APP] (2) The means by which an application 
designer enters and retrieves information. 


Architecture—Architecture has various meanings depending upon its contextual usage. (1) The 
structure of components, their interrelationships, and the principles and guidelines governing 
their design and evolution over time. [IEEE STD 610.12] (2) Organizational structure of a 
system or component. [IEEE STD 610.12] 


Architecture, Database-The logical view of the data models, data standards, and data structure. 
It includes a definition of the physical databases for the information system, their performance 
requirements, and their geographical distribution. Ref DoD 8020.1-M, Appendix J 


Architecture Target—Depicts the configuration of the target open information system. Ref DoD 
8020.1-M 


Architecture, Infrastructure—Identifies the top-level design of communications, processing, 
and operating system software. It describes the performance characteristics needed to meet 
database and application requirements. It provides a geographic distribution of components to 
locations. The infrastructure architecture is defined by the service provider for these capabilities. 
It includes processors, operating systems, service software, and standards profiles that include 
network diagrams showing communication links with bandwidth, processor locations, and 
capacities to include hardware builds versus schedule and costs. [DoD 8020.1-M, Appendix J 
specifically paragraph 5(14)(c), Table J-2] 


Architectural Structure—Provides the conceptual foundation of the basic architectural design 
concepts, the layers of the technical architecture, the services provided at each layer, the 
relationships between the layers, and the rules for how the layers are interconnected. 


Automated Information System (AIS)—-Computer hardware, computer software, 
telecommunications, information technology, personnel, and other resources that collect, record, 
process, store, communicate, retrieve, and display information. An AIS can include computer 
software only, computer hardware only, or a combination of the above. [DoDD 8000.1] 
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Baseline—A specification or product that has been formally reviewed and agreed upon, that 
thereafter serves as the basis for further development and that can be changed only through 
formal change control procedures or a type of procedure such as configuration management. 
[IEEE STD 610.12] 


Commercial-Off-The-Shelf (COTS)-Refers to an item of hardware or software that has been 
produced by a contractor and is available for general purchase. Such items are at the unit level or 
higher. Such items must have been sold and delivered to government or commercial customers, 
must have passed customer’s acceptance testing, be operating under customer’s control, and 
within the user environment. Further, such items must have meaningful reliability, 
maintainability, and logistics historical data. 


Communications Link-The cables, wires, or paths that the electrical, optical, or radio wave 
Signals traverse. [TA] 


Communications Network-—A set of products, concepts, and services, that enable the connection 
of computer systems for the purpose of transmitting data and other forms (e.g., voice and video) 
between the systems. 


Communications Node—A node that is either internal to the communications network (e.g., 
routers, bridges, or repeaters) or located between the end device and the communications 
network to operate as a gateway. [TA] 


Communications Services—A service of the Support Application entity of the Technical 
Reference Model that provides the capability to compose, edit, send, receive, forward, and 
manage electronic and voice messages and real time information exchange services in support of 
interpersonal conferencing. [TA] 


Communications System-A set of assets (transmission media, switching nodes, interfaces, and 
control devices) that will establish linkage between users and devices. 


Configuration Management-A discipline applying technical and administrative direction and 
surveillance to: (a) identify and document the functional and physical characteristics of a 
configuration item, (b) control changes to those characteristics, and (c) record and report changes 
to processing and implementation status. 


Connectivity Service—A service area of the External Environment entity of the Technical 
Reference Model that provides end-to-end connectivity for communications through three 
transport levels (global, regional, and local). It provides general and applications-specific 
services to platform end devices. [TA] | 


Database Utility Service—A Service of the Support Application Entity of the Technical 
Reference Model that provides the capability to retrieve, organize, and manipulate data extracted 
from a database. [TA] 


Data Dictionary—A specialized type of database containing metadata, which is managed by a 
data dictionary system; a repository of information describing the characteristics of data used to 
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design, monitor, document, protect, and contro] data in information systems and databases; an 
application of data dictionary systems. [DoDD 8320.1] 


Data Element~A basic unit of information having a meaning and that may have subcategories 
(data items) of distinct units and values. [DoDD 8320.1] 


Data Interchange Service—A service of the Platform entity of the Technical Reference Model 
that provides specialized support for the interchange of data between applications on the same or 
different platforms. [TA] 


Data Management Service-A service of the Platform entity of the Technical Reference Model 
that provides support for the management, storage, access, and manipulation of data in a 
database. [TA] 


Directory Service—A service of the External Environment entity of the Technical Reference 
Model that provides locator services that are restricted to finding the location of a service, 
location of data, or translation of acommon name into a network specific address. It is 
analogous to telephone books and supports distributed directory implementations. [TA] 


Distributed Database-(1) A database that is not stored in a central location but is dispersed over 
a network of interconnected computers. (2) A database under the overall control of a central 
database management system but whose storage devices are not all attached to the same 
processor. (3) A database that is physically located in two or more distinct locations. [FIPS PUB 
11-3) 


Enterprise—The highest level in an organization — includes all missions and functions. [TA] 


Enterprise Model-A high-level model of an organization’s mission, function, and information 
architecture. The model consists of a function model and a data model. 


External Environment Interface (EEI)-The interface that supports information transfer 
between the application platform and the external environment. [APP] 


Functional Architecture-The framework for developing applications and defining their 
interrelationships in support of an organization's information architecture. It identifies the major 
functions or processes an organization performs and their operational interrelationships. [DoD 
5000.11-M] 


Functional Area—A range of subject matter grouped under a single heading because of its 
similarity in use or genesis. [DoDD 8320.1] 


Function—Appropriate or assigned duties, responsibilities, missions, tasks, powers, or duties of 
an individual, office, or organization. A functional area is generally the responsibility of a PSA 
(e.g., personne!) and can be composed of one or more functional activities (e.g., recruiting), each 
of which consists of one or more functional processes (e.g., interviews). Ref Joint Pub 1-02, 
DoDD 8000.1, and DoD 8020-1M. 
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Functional Activity Program Manager (FAPM)-FAPMs are designated by PSAs and are 
accountable for executing the functional management process. Supported by functional 
representatives from the DoD Components, FAPMs develop functional architectures and 
Strategic plans, and establish the process, data, and information system baselines to support 
functional activities within the functional area Ref DoD 8020.1-M Ch 1 B(2). 


Functional Data Administrator (FDAd)—OSD PSAs exercise or, designate functional data 
administrators to perform data administrator responsibilities to support execution of the 
functional management process, and to function within the scope of their overall assigned 
responsibilities. Ref DoDD 8320.1 and DoD 8020.1-M, Appendix A. 


Functional Economic Analysis (FEA)—A structured proposal that serves as the principal part of 
a decision package for enterprise (individual, office, organization - see function) leadership. It 
includes an analysis of functional! process needs or problems; proposed solutions, assumptions, 
and constraints; alternatives; life-cycle costs; benefits and/or cost analysis; and investment risk 
analysis. It is consistent with, and amplifies, existing DoD economic analysis policy. Ref DoDI 
7041.3, DoDD 8000.1, and DoD 8020.1-M, Appendix H. 


Hardware-(!) Physical equipment, as opposed to programs, procedures, rules, and associated 
documentation. (2) Contrast with software. [FIPS PUB 11-3] 


Information—Any communication or representation of knowledge such as facts, data, or 
opinions, in any medium or form, including textual, numerical, graphic, cartographic, narrative, 
or audiovisual forms. [OMB CIRC A-130] 


Information Domain-A set of commonly and unambiguously labeled information objects with a 
common security policy that defines the protections to be afforded the objects by authorized 
users and information management systems. [DISSP] 


Information Management(IM)-The creation, use, sharing, and disposition of information as a 
resource critical to the effective and efficient operation of functional activities. The structuring 
of functional processes to produce and contro! the use of data and information within functional 
activities, information systems, and computing and communications infrastructures. [DoDD 
8000.1) 


Information Resources Management (IRM)-The planning, budgeting, organizing, directing, 
_ training, promoting, controlling, and management activities associated with the burden (cost), 
collection, creation, use, and dissemination of information by Agencies and includes the 
management of information and related resources, such as federal information processing (FIP) 
resources. Ref PL No 99-591, DoDD 8000.1. 


Information Technology (IT)-The technology included in hardware and software used for 
Government information, regardless of the technology involved, whether computers, 
communications, micro graphics, or others. Ref OMB Circular A-130 and DoDD 8000.1. 


Infrastructure—Infrastructure is used with different contextual meanings. Infrastructure most 
generally relates to and has a hardware orientation but note that it is frequently more 
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comprehensive and includes software and communications. Collectively, the structure must meet 
the performance requirements of and capacity for data and application requirements. Again note 
that just citing standards for designing an architecture or infrastructure does not include 
functional and mission area requirements for performance. Performance requirement metrics 
must be an inherent part of an overall infrastructure to provide performance interoperability and 
compatibility. It identifies the top-level design of communications, processing, and operating 
system software. It describes the performance characteristics needed to meet database and 
application requirements. It provides a geographic distribution of components to locations. The 
infrastructure architecture is defined by the service provider for these capabilities. It includes 
processors, operating systems, service software, and standards profiles that include network 
diagrams showing communication links with bandwidth, processor locations, and capacities to 
include hardware builds versus schedule and costs. Ref DoD 8020.1-M | 


Interoperability—-The ability of systems to exchange useful data and information. 


Legacy Environments—Legacy environments could be called legacy architectures or 
infrastructures and as a minimum consist of a hardware platform and an operating system. 
Legacy environments are identified for phase-out, upgrade, or replacement. All data and 
applications software that operate in a legacy environment must be categorized for phase-out, 
upgrade, or replacement. 


Legacy Systems-Systems that are candidates for phase-out, upgrade, or replacement. Generally 
legacy systems are in this category because they do not comply with data standards or other 
standards. Legacy system workloads must be converted, transitioned, or phased out (eliminated). 
Such systems may or may not operate in a legacy environment. 


Life Cycle-The period of time that begins when a system is conceived and ends when the system 
is no longer available for use. [IEEE STD 610.12]. AIS life cycle is defined within the context 
of life-cycle management in various DoD publications. It generally refers to the usable system 
life. 


Local Area Network (LAN)-A data network, located on a user’s premises, within a limited 
geographic region. Communication within a local area network is not subject to external 
regulation; however, communication across the network boundary may be subject to some form 
of regulation. [FIPS PUB 11-3]. 


Migration Systems—An existing AIS, or a planned and approved AIS, that has been officially 
designated to support common processes for a functional activity applicable to use DoD-wide or 
DoD Component-wide. Systems in this category, even though fully deployed and operational, 
have been determined to accommodate a continuing and foreseeable future requirement and, 
consequently, have been identified for transitioning to a new environment or infrastructure. A 
migration system may need to undergo transition to the standard technical environment and 
standard data definitions being established through the Defense IM Program, and must “migrate” 
toward that standard. In that process it must become compliant with the Reference Model and 
the Standards Profile. A system in this category may require detailed analysis that involves a 
total redesign, reprogramming, testing, and implementation because of a new environment and 


Volume 3 Version 3.0 
Architecture Concepts and Design Guidance B-8 | 30 April 1996 


how the “users” have changed their work methods and processes. The detailed analysis may 
identify the difference between the “‘as 1s” and the “to be” system. [DoD 8020.1-M]. 


Multimedia Service—A service of the TRM that provides the capability to manipulate and 
manage information products consisting of text, graphics, images, video, and audio. [TA] 


Open Specifications—Public specifications that are maintained by an open, public consensus 
process to accommodate new technologies over time and that are consistent with international 
standards. [P1003.0/D15] 


Open System-A system that implements sufficient open specifications for interfaces, services, 
and supporting formats to enable properly engineered applications software: (a) to be ported with 
minimal changes across a wide range of systems, (b) to interoperate with other applications on 
local and remote systems, and (c) to interact with users in a style that facilitates user portability. 
[P1003.0/D15] 


Open Systems Environment (OSE)-The comprehensive set of interfaces, services, and 
supporting formats, plus user aspects for interoperability or for portability of applications, data, 
or people, as specified by information technology standards and profiles. [P1003.0/D15] 


Operating System Service—A core service of the Platform entity of the Technical Reference 
Mode] that is needed to operate and administer the application platform and provide an interface 
between the application software and the platform (e.g., file management, input/output, print 
spoolers). [TA] 


Platform-The entity of the Technical Reference Model that provides common processing and 
communication services that are provided by a combination of hardware and software and are 
required by users, mission area applications, and support applications. [TA] 


Portability—(1) The ease with which a system or component can be transferred from one 
hardware or software environment to another. [IEEE STD 610.12] (2) A quality metric that can 
be used to measure the relative effort to transport the software for use in another environment or 
to convert software for use in another operating environment, hardware configuration, or 
software system environment. [IEEE TUTOR] (3) The ease with which a system, component, 
data, or user can be transferred from one hardware or software environment to another. [TA] 


Process Model—Provides a framework for identifying, defining, and organizing the functional 
Strategies, functional rules, and processes needed to manage and support the way an organization 
does or wants to do business--provides a graphical and textual framework for organizing the data 
and processes into manageable groups to facilitate their shared use and control throughout the 
organization. [DoD 5000.11-M] 


Profile—A set of one or more base standards, and, where applicable, the identification of those 
classes, subsets, options, and parameters of those base standards, necessary for accomplishing a 
particular function. [P1003.0/D15] 


Profiling—Selecting standards for a particular application. [P1003.0/D15] 
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Scalability-The ability to use the same application software on many different classes of 
hardware/software platforms from personal computers to super computers (extends the 
portability concept). [USAICII]. The capability to grow to accommodate increased work loads. 


Seamless Interface—Ability of facilities to call one another or exchange data with one another in 
a direct manner. Integration of the user interface that allows a user to access one facility through 
another without any noticeable change in user interface conventions. [DSAC SYS IM] 


Stovepipe System—A system, often dedicated or proprietary, that operates independently of other 
systems. The stovepipe system often has unique, nonstandard characteristics. 


System—People, machines, and methods organized to accomplish a set of specific functions. 
[FIPS PUB 11-3] 


System Management Service—A service of the Platform entity of the TRM that provides for the 
administration of the overall information system. These services include the management of 
information, processors, networks, configurations, accounting, and performance. [TA] 


Technical Reference Model (TRM)-The document that identifies a target framework and 
profile of standards for the DoD computing and communications infrastructure. [TRM] 


User-(1) Any person, organization, or functional unit that uses the services of an information 
processing system. (2) In a conceptual schema language, any person or any thing that may issue 
or receive commands and messages to or from the information system. [FIPS PUB 11-3] 


User Interface Service—A service of the Platform entity of the Technical Reference Model that 
supports direct human-machine interaction by controlling the environment in which users interact 
with applications. [TA] 
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APPENDIX C 


OPEN SYSTEMS 


A critical objective of the DoD Information Management initiative is the implementation of a 
computing and communications infrastructure that supports portability, interoperability, and 
scalability. To achieve this objective the DoD must develop and use open systems. The 
following definitions apply to open systems: 


e OPEN SYSTEM: A system that implements sufficient open specifications for 
interfaces, services, and supporting formats to enable properly engineered hardware and 
applications software to: 


- Interoperate with other applications on local and remote systems 


- Be ported with minimal changes across a wide range of systems 
- Interact with users in a style that facilitates user portability 


- Enable users to increase processing power as their functional needs grow, without the 
need to re-write applications (i.e., scalability) 


e OPEN SPECIFICATION: Public specifications that are maintained by an open, public 
consensus process to accommodate new technologies over time and that are consistent 
with international standards. 


e OPEN SYSTEM ENVIRONMENT (OSE): The comprehensive set of interfaces, 
services, and supporting formats, plus user aspects for interoperability and scalability, 
or for portability of applications, data, or people, as specified by information technology 
standards and profiles. 


¢ OPEN SYSTEM ARCHITECTURE: The framework describing the entities (e.g., 
components, services) and their interrelationships in an open system. 


Open systems environments and architectures are intended to help achieve portability, 
interoperability, scalability and cost effectiveness of systems. These attributes facilitate 
technology insertion and rapid system evolution to respond to changing functional practices — 
functional and technical managers will have the capability to selectively preserve or reconfi gure 
parts of the infrastructure based on functional needs. 


Open systems are modular, enabling users to define, acquire, and add to systems that are supplied 
by a variety of vendors in an open, competitive market. An open system supports the 
interoperability of hardware, software, and communications products developed by different 
suppliers at different times. 
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DoD information systems will incrementally evolve to converge towards open system 
architecture guidelines and standards while accommodating existing baselines and transition 
environments. Implementation guidelines will be provided for engineering and economic 
analysis of options and opportunities to evolve baselines to target architectures. They will 
support the decision making process to select the best overall targets and transition paths. 
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APPENDIX D 


PROPOSING CHANGES TO TAFIM VOLUMES 


D.1 INTRODUCTION 


Changes to the TAFIM will occur through changes to the TAFIM documents (i.e., the TAFIM 
numbered volumes, the CMP, and the PMP). This appendix provides guidance for submission of 
proposed TAFIM changes. These proposals should be described as specific wording for 
line-in/line-out changes to a specific part of a TAFIM document. 


Use of a standard format for submitting a change proposal will expedite the processing of 
changes. The format for submitting change proposals is shown in Section D.2. Guidance on the 
use of the format is provided in Section D.3. 


A Configuration Management contractor is managing the receipt and processing of TAFIM 
change proposals. The preferred method of proposal receipt is via e-mail in ASCII format, sent 
via the Internet. If not e-mailed, the proposed change, also in the format shown in Section D.2, 
and on both paper and floppy disk, should be mailed. As a final option, change proposals may be 
sent via fax; however, delivery methods that enable electronic capture of change proposals are 
preferred. Address information for the Configuration Management contractor is shown below. 


Internet: tafim@bah.com 


Mail: TAFIM 
Booz Allen & Hamilton Inc. 
5201 Leesburg Pike, 4th Floor 
Falis Church, VA 22041 


Fax: 703/671-7937. indicate “TAFIM” on cover sheet. 


D.2 TAFIM CHANGE PROPOSAL SUBMISSION FORMAT 


a. Point of Contact Identification 
(1) Name: 

(2) Organization and Office Symbol: 
(3) Street: 

(4) City: 

(5) State: 

(6) Zip Code: 
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(7) Area Code and Telephone #: 
(8) Area Code and Fax #: 
(9) E-mail Address: 


b. Document Identification 
(1) Volume Number : 

(2) Document Title: 

(3) Version Number: 

(4) Version Date: 


c. Proposed Change # 1 

(1) Section Number: 

(2) Page Number: 

(3) Title of Proposed Change: 

(4) Wording of Proposed Change: 
(5) Rationale for Proposed Change: 
(6) Other Comments: 


d. Proposed Change # 2 

(1) Section Number: 

(2) Page Number: 

(3) Title of Proposed Change: 

(4) Wording of Proposed Change: 
(5) Rationale for Proposed Change: 
(6) Other Comments: 


n. Proposed Change #n 

(1) Section Number: 

(2) Page Number: 

(3) Title of Proposed Change: 

(4) Wording of Proposed Change: 
(5) Rationale for Proposed Change: 
(6) Other Comments: 
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D.3 FORMAT GUIDANCE 


The format in Section D.2 should be followed exactly as shown. For example, Page Number 
should not be entered on the same line as the Section Number. The format can accommodate, for 
a specific TAFIM document, multiple change proposals for which the same individual is the 
Point of Contact (POC). This POC would be the individual the TAFIM project staff could 
contact on any question regarding the proposed change. The information in the Point of Contact 
Identification part (D.2 a) of the format would identify that individual. The information in the 
Document Identification part of the format (D.2 b) is self-evident, except that volume number 
would not apply to the CMP or PMP. The proposed changes would be described in the 
Proposed Change # parts (D.2 c, D.2 d, or D.2 n) of the format. 


In the Proposed Change # parts of the format, the Section number refers to the specific 
subsection of the document in which the change is to take place (e.g., Section 2.2.3.1). The page 
number (or numbers, if more than one page is involved) will further identify where in the 
document the proposed change is to be made. The Title of Proposed Change field is for the 
submitter to insert a brief title that gives a general indication of the nature of the proposed 
change. In the Wording of Proposed Change field the submitter will identify the specific words 
(or sentences) to be deleted and the exact words (or sentences) to be inserted. In this field 
providing identification of the referenced paragraph, as well as the affected sentence(s) in that 
paragraph, would be helpful. An example of input for this field would be: “Delete the last 
sentence of the second paragraph of the section and replace it with the following sentence: “The 
working baseline will only be available to the TAFIM project staff.” The goal is for the 
commentor to provide proposed wording that is appropriate for insertion into a TAFIM document 
without editing (i.e., a line-out/line-in change). The D.2 ς (5), D.2 ἃ (5), or D.2 n (5) entry in this 
part of the format is a discussion of the rationale for the change. The rationale may include 
reference material. Statements such as “industry practice” would carry less weight than specific 
examples. In addition, to the extent possible, citations from professional publications should be 
provided. A statement of the impact of the proposed change may also be included with the 
rationale. Finally, any other information related to improvement of the specific TAFIM 
document may be provided in D.2 c (6), D.2 d (6), or D.2 n (6) (i.e., the Other Comments field). 
However, without some degree of specificity these comments may not result in change to the 
document. 
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